ВОПРОСЫ
к билетам государственных экзаменов (1994/1995 г.) по дисциплине ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ 1. Значение и направления развития проектирования информаци-
онных систем, предназначенных для обработки экономической инфор-
мации; проблемы проектирования автоматизированных экономических
информационных систем (АЭИС) (14.1). 2. Порядок разработки автоматизированных экономических ин-
формационных систем (АЭИС); нормативная последовательность этапов
разработки АЭИС: технические предложения,технические требования
или техническое задание; эскизный проект; технический проект; ра-
бочий проект (19.1.) 3. Организация проектирования автоматизированных экономичес-
ких информационных систем; принципы планирования разработки АЭИС
(15.1.). 4. Виды поддержки процесса проектирования автоматизированных
информационных систем (АЭИС); документирование; цели проектирова-
ния АЭИС (32.1.). 5. Жизненный цикл; эффективность технологии проектирования
автоматизированных экономических информационных систем (АЭИС)
(16.1). 6. Технологические аспекты проектирования автоматизированных
экономических информационных систем (АЭИС) (17.1). 7. Системотехнические принципы проектирования автоматизиро-
ванных экономических информационных систем (АЭИС); классы систем
- объектов проектирования; декомпозиция как метод проектирования
сложных АЭИС (18.1). 8. Принципы структурного проектирования автоматизированных
экономических информационных систем (АЭИС); структурное проекти-
рование программных компонент; восходящее и нисходящее проектиро-
вание АЭИС; общие правила структурного построения (20.2.). 9. Элементарные базовые структуры автоматизированных эконо-
мических информационных систем (АЭИС); структурирование данных
АЭИС; типовая структура АЭИС; основные режимы функционирования
систем (21.1.). 10. Проектирование аппаратных средств автоматизированных
экономических информационных систем (АЭИС); модульная структура
аппаратных средств; вопросы экономики при выборе соотношения меж-
ду аппаратными и программными средствами (22.1.). 11. Проектирование программного обеспечения автоматизирован-
ных экономических информационных систем (АЭИС); система языков
проектирования программ; комплексирование программ; средства ав-
томатизации разработки программ (23.1.). 12. Проектирование программного обеспечения: понятие кор-
ректности, эталона и сложности программ; программные ошибки
(24.1.). 13. Методы распределения ресурсов, эффективность распределе-
ния производительности и памяти при проектировании автоматизиро-
ванных экономических информационных систем (АЭИС). 14. Системы автоматизации проектирования автоматизированных
экономических информационных систем (АЭИС); состав инструменталь-
ных средств для различных уровней автоматизации разработки АЭИС;
структурная схема комплексной системы автоматизации сложных АЭИС
(26.1.). 15. Основные понятия надежности автоматизированных экономи-
ческих информационных систем (АЭИС); методы повышения надежности
функционирования АЭИС; методы проектирования систем с заданными
надежностью и качеством (25.1.). 16. Проектирование автоматизированных экономических информа-
ционных систем на базе персональных ЭВМ; особенности и технологи-
ческие аспекты проектирования АЭИС, создаваемых на основе ПЭВМ;
обоснование выбора состава автоматизированных функций при созда-
нии и проектировании АЭИС (31.1). 17. Проблемы выбора языка программирования при проектирова-
нии АЭИС на базе ПЭВМ; фреймовый подход к организации объектной
базы. 18. Особенности разработки прикладных информационных систем
на основе ПЭВМ; структурирование программ на уровне модулей; раз-
дельно компилируемые модули; библиотеки процедур; генерация объ-
ектных модулей и загрузочных файлов; библиотеки объектных моду-
лей; реализация сегментированных программ с перекрытиями (4.2.). 19. Организация взаимодействия программ АЭИС на основе ПЭВМ:
через прерывания ДОС; на языке ассемблера; особенности ассемблер-
ных процедур; резидентные программы; связывание программ через
потоки ввода/вывода (5.2.). 20. Автономная отладка и тестирование АЭИС; общие задачи от-
ладки; содержание тестирования; систематизация тестов для отлад-
ки; используемые методы отладки; этапы отладки; отладка программ-
ных модулей; тестирование обработки данных; планирование отладки;
системы автоматизации отладки (27.1). 21. Комплексная отладка АЭИС; задачи комплексной отладки;
статическая и динамическая комплексная отладка; регистрация и об-
работка данных при отладке программ (28.1). 22. Организация работ по проведению испытаний информационных
систем; организация проведения приемочных испытаний систем; осо-
бенности испытаний на надежность систем; достоверность определе-
ния качества систем при испытаниях; исходные и отчетные документы
при испытаниях систем (29.1). 23. Организация работ по сопровождению информационных сис-
тем; задачи сопровождения; иерархия подготовки и внесения измене-
ний в систему; тиражирование и использование версий системы
(30.1.). 1. Значение и направления развития проектирования информаци-
онных систем, предназначенных для обработки экономической инфор-
мации; проблемы проектирования автоматизированных экономических
информационных систем (АЭИС) (14.1). Мировая экономика - широко разветвленная научная отрасль,
имеющая мощную информационную базу (только в США выходит более
500 наименований журналов по экономике и бизнесу). В нашей стране
проблема проектирования АЭИС стоит особенно остро, если учесть,
что до недавнего времени экономическая теория обслуживала, глав-
ным образом, государственные органы власти разного уровня, а сама
экономика была самозамкнутой, с минимальным участием в междуна-
родном разделении труда. Сложилась устойчивая система информаци-
онного обеспечения государственного сектора. Существует также более общая проблема, связанная с ролью и
местом информационных процессов в обществе. В современных услови-
ях эффективность информатизации определяется качеством информаци-
онных связей, уровнем общения различных участников процесса ком-
муникаций, обусловленным проникновением информатизации во все
сферы общественной жизни - идеологию, мораль, политику, религию,
медицину, образования и т.д., не говоря уже о экономике. В условиях наметившейся информатизации общества большое зна-
чение придается разработке и проектированию экономических инфор-
мационных систем, обслуживающих сферы с высоком уровнем потребле-
ния вычислительной техники. Открываются новые возможности, свя-
занные с динамичностью проведения экономических реформ и появле-
нием новых форм хозяйственной деятельности (Например, создание
информационных систем, реагирующих на изменение состояния рынка).
С каждым днем все большая часть экономических и финансовых дан-
ных, относящихся к производственной сфере, банковским и коммер-
ческим расчетам, социально-бытовому и транспортному обслуживанию,
здравоохранению, национальной безопасности и личной жизни, дове-
ряются информационным системам, базирующимся на надежной и удоб-
ной как аппаратной, так и программной основе, воплощенных в самом
массовом классе вычислительной техники - ПЭВМ. В маркетинговой деятельности информатизация позволяет перей-
ти к новым формам работ: анализ потребительского спроса, модели-
рование развития общественных потребностей и возможностей их
удовлетворения, автоматизации процессов заключения договоров на
поставку продукции и контроля за их исполнением. Многие хозяйс-
твенные структуры, связанные стабильными договорными отношениями,
создают информационные системы, позволяющие заказчику контролиро-
вать ход выполнения заказа у подрядчика. Создаются высокоавтома-
тизированные системы рыночных взаимодействий, которые предъявляют
повышенные требования к информационному обеспечению экономических
структур: те хозяйства, которые не будут иметь развитых систем в
сфере маркетинга, не смогут нормально функционировать на внутрен-
нем и внешнем рынках. Наличие теких систем является необходимым
условием рыночной интеграции. Назначение информационной системы (ИС) - поиск и анализ ин-
формации, потребителем которой является человек. Основу алгорит-
мов такой системы составляют программы логической обработки дан-
ных. Объем входной информации в таких системах невелик, но в них
имеются большие постоянные или медленно изменяющиеся массивы дан-
ных. Воздействие ИС на все области человеческой деятельности
предъявляет ряд требований, которые должны быть учтены при проек-
тировании и сопровождении АЭИС, и гарантирующих, что последние
являются: исключительно надежными; естественными; удобными в ис-
пользовании; оставляющими главную роль за человеком, а на за ма-
шиной; проверяемыми; труднодоступными для злоупотреблений. Анализ я_значимостия. для общества информационных и вычислитель-
ных систем является частью работы по их проектированию, а методы
проведения этого анализа должны быть включены в практическую ме-
тодологию проектирования. Система состоит из компонентов, выпол-
няющих определенные функции по отношению к ее внешнему окружению.
Чтобы иметь возможность воспринимать информацию извне и переда-
вать ее во внешнее окружение, система должна иметь я_входы я.и я_выхо-
я_дыя.. АЭИС представляет собой человеко-машинный комплекс, в котором
экономическая информация обрабатывается с помощью ЭВМ, а резуль-
таты обработки используются человеком для принятия решения. Цель проектирования, направленная на достижение конечного
результата, может быть представлена в виде иерархической структу-
ры: ЙННННННННННННННННННННННННННН” ЪДД¶ Успешность проектирования ЗДДДДї і ИНННННННННННННННННННННННННННј і
ЙННННННННННННННПНННННННННННННН” ЙННННННННННННННПНННННННННННННН”
Качество є є Эффективность процесса є
системы є є разработки системы є
ИННННННННННННННСННННННННННННННј ИННННННННННННННСННННННННННННННј ЪДДДДДДДДДБВДДДДДДДДДДї ЪДДДДДДДДДДВБДДДДДДДДДї
ЙННННПНННН”ЙННННПНННН”ЙННННПНННН” ЙННННПНННН”ЙННННПНННН”ЙННННПНННН”
Челове- єє Управле-єє Програм-є є Челове- єє Управле-єє Програм-є
ческие єє ние ре-єє мотехни-є є ческие єє ние ре-єє мотехни-є
факторы єє сурсами єє ка є є факторы єє сурсами єє ка є
ИСННННННННјИСННННННННјИСННННННННј ИСННННННННјИСННННННННјИСННННННННј ГЛегкость ГЭффектив- ГСпецифиро- ГПланируе- ГАнализиру-ГОсуществи- іиспользо- іность іванность: імость іемость эф-імость івания і і полнота ГОрганизо- іфективнос-ГПолнота и ГУдовлетво-АИзмеряе- і безопас- іванность іти затрат іосуществи- ірение пот- мость і ность ГУкомплек- і імость тре- іребностей і непротиво-ітованностьГПланируе- ібований іпользова- і чивость іштатов імость ГПроектиру- ітеля і осуществи-ГРуководи- і іемость из- ГРеализация і мость імость АКонтроли- іделия іпотенциа- і проверяе- ГКонтроли- руемость ГПрограм- ільных спо- і мость іруемость імируемость ісобностей ГПравиль- ГАвтомати- ГКомплекси- іпользова- іность ізируемость іруемость ітеля ААдаптируе- АСледование ГВнедряе- АСледование мость: модифици- імость модифици- структури- рованному ГСопровож- рованному рованность золото- ідаемость му золотому независи- правилу ГСнимае- правилу мость імость понятность АУправляемость конфигурацией Проектирование АЭИС включает в себя также создание качест-
венной документации, формирование и ведение баз данных и разра-
ботку процедур работы с системой. Проектирование АЭИС должно про-
водиться на системной основе с целью минимизации как стоимости
проектирования, так и времени, затрачиваемого на разработку. При решении задач проектирования ИС на основе ПЭВМ критичным
является состояние дела с людскими ресурсами. В то время, как ко-
личество и сложность аппаратуры возрастает значительными темпами
(и этому росту не видно никаких физических ограничений), соот-
ветствующий рост программного обеспечения (ПО) ограничен интел-
лектуальным и социальным уровнем развития общества. Производи-
тельность труда при разработке ПО относительно низка и удовлетво-
рение спроса возможно только за счет дополнительного привлечения
людских ресурсов. На рубеже 80-х г.г. Дж.Мартин выступил с проек-
том, названным новой информационной технологией (НИТ). Необходи-
мость НИТ обуславливалась тем, что длительность традиционных ме-
тодов разработки информационных систем превосходила время безус-
ловного морального старения их спецификаций. С момента, когда бы-
ли сформированы и утверждены требования к будущей системе и до
начала ее опытной эксплуатации эти требования безнадежно устаре-
вали. Для выхода из этой ситуации было предложено участие в про-
цессе создания и проектирования системы будущих пользователей.
Используя языки программирования сверхвысокого уровня, специаль-
ные языки запросов к базам данных, и специальные языки для фор-
мальных спецификаций, пользователь, согласно замыслу автора НИТ,
должен был реализовать прототип будущей системы, который предус-
матривал все нужные функции, но не удовлетворял требованиям эф-
фективности использования ресурсов. Это реализовывалось професси-
ональными программистами, которые формировали ПО будущей системы.
Первый шаг к НИТ был сделан, когда ПЭВМ стали применяться при ре-
шении практических задач, таких как управление деятельностью
предприятий, планирование, информационный поиск в больших масси-
вах информации, т.е. с появлением качественно нового типа - ИС. Сложился также определенный комплекс требований для ПЭВМ.
Это можно продемонстрировать примером, характерным для США, где
предъявляют семь основных четко сформировавшихся требований для
ПЭВМ:1) цена всей системы не должна превышать 5000 дол.; 2) система включает внешние запоминающие устройства (накопи-
тели на компакт-диска или на магнитных дисках); 3) емкость ОЗУ составляет не менее 64 Кбайт; 4) в состав ПО входит по крайней мере один из языков прог-
раммирования высокого уровня (Бейсик, Фортран или Паскаль); 5) имеется операционная система, способная поддерживать диа-
логовое взаимодействие с пользователем; 6) распространение ПЭВМ осуществляется на основе сети сбыта
с ориентацией на людей, не обладающих навыками работы с ВТ; 7) система обладает достаточной гибкостью для поддержки
прикладного ПО, она в известном смысле является универсальной. Создание АЭИС с использованием ПЭВМ позволяет: - обеспечивать работников управленческий сферы и финансово-
экономических служб оперативной информацией вместо обезличенного
представления информации функциональному подразделению в целом; - получать комплексную информацию на основе данных всех под-
систем управления хозяйственной и коммерческой деятельностью; - создать многоуровневый интегрированный банк данных и обес-
печить диалоговый режим общения пользователя с системой через ав-
томатизированные рабочие места (АРМ); - снизить объем выходных бумажных документов (так называемых
машинограмм) в три-четыре раза; - сократить время поиска информации в системе, а также ее
обработки, подготовки и выпуска различной организационно-распоря-
дительной документации; - автоматизировать функции контроля исполнения на всех уров-
нях управления и экономической деятельности; - автоматизировать ведение локальной информации конечных
пользователей и создавать локальные базы данных; - дать возможность пользователям работать с имеющейся в бан-
ке данных информацией как в составе общей сети, так и автономно. Главной проблемой, стоящей в настоящее время перед проекти-
ровщиками ИС, является обеспечение быстро расширяющегося сооб-
щества конечных пользователей удобным интерфейсом, т.е. создавать
такие АЭИС, которые позволили бы пользователю выполнять с помощью
ЭВМ необходимые действия без глубокого изучения в полном объеме
специальной литературы по ВТ. Особенно остро это стало в связи со
скачкообразным развитием микроэлектронной технологии и широким
выходом на мировой рынок ПЭВМ, снижением стоимости аппаратных
средств и существенным увеличением возможностей ПО за счет боль-
шого объема памяти, более полного набора команд и т.д. Современный уровень научно-технического развития выдвигает
определенные принципы проектирования ИС, включая и экономические.
Разработка этих принципов направлена на обеспечение создания на-
дежных систем и повышение эффективности самого процесса проекти-
рования. Актуальность задачи вызвана следующим: - объекты АЭИС становятся более крупномасштабными и дороги-
ми, что приводит к их удорожанию и увеличению сроков проектирова-
ния; ошибки, допущенные в процессе проектирования, приводят к су-
щественным затратам материальных и трудовых ресурсов; - растет сложность АЭИС: возрастает число решаемых задач,
простейшие задачи стабилизации уступают место сложным задачам са-
монастройки системы на оптимум показателей; одновременно с ростом
числа задач сокращается допустимое время принятия решений; - проектирование начинается и проводится в условиях неопре-
деленности, т.е. при отсутствии в полном объеме информации, необ-
ходимой для выбора решений. Для комплексного решения проблем проектирования необходимо
широкое обеспечение процесса средствами автоматизации всего жиз-
ненного цикла АЭИС, начиная от формулирования исходных требований
и кончая завершением промышленного производства и эксплуатации. Рост спроса на АЭИС предъявляет требования к самому проекти-
рованию: повысить производительность труда при разработке; повы-
сить эффективность сопровождения, т.к. последнее требует больших
затрат, чем непосредственно разработка.
2. Порядок разработки автоматизированных экономических ин-
формационных систем (АЭИС); нормативная последовательность этапов
разработки АЭИС: технические предложения,технические требования
или техническое задание; эскизный проект; технический проект; ра-
бочий проект (19.1.) Основанием для начала работ по созданию АЭИС могут быть ре- ЪДДДДДДДДДДДДДДДДДї шения как государственных органов, так іРазработка техни-і и коммерческих структур и различных ор- іческих предложен.і ганизаций, функционирующих в обществен- АДДДДДДДДВДДДДДДДДЩ но-социальной сфере. В создании участ- ЪДДВДДДДДДДДБДДДДДДДДї вуют как заказчик (организация, для ко- іЪДґРазработка ТЗ илиГї торой разрабатывается АЭИС), так и ис- ііЪґтехнич.требованийіі полнитель - как специализированная ор- іііАДДДДДДДДВДДДДДДДДЩі ганизация, так и отдельно созданный для іііЪДДДДДДДДБДДДДДДДДїі этой цели коллектив. ііАґ Эскизное ГЕДДДДДДДДДДї Весь период создания іі і проектирование іі і АЭИС состоит из этапов. В іі АДДДДДДДДВДДДДДДДДЩі і зависимости от того, в ка- іі ЪДДДДДДДДБДДДДДДДДїі ЪДДДДДДДДБДДДДДДДДї кой степени при іАДґ Техническое ГЩ і Макетирование и і проекровании испо- і і проектирование ГДДґоценочн.программ.і льзуются готовые і АДДДДДДДДВДДДДДДДДЩ АДДДДДДДДДДДДДДДДДЩ или известные тех- і ЪДДДДДДДДБДДДДДДДДї нические решения и методология, неко- іЪДґ Разработка рабо-і торые этапы могут объединяться. ііЪґ чих чертежей ГДї В других случаях, напротив, от- іііАДДДДДДДДВДДДДДДДДЩ і дельные этапы (например, эскизное или іііЪДДДДДДДДБДДДДДДДДї і техническое проектирование) могут до- ііАґ Изготовление Гїі полняться экспериментальными работами іі іопытного образцаііі для исследования новых решений, схем и іі АДДДДДДДДВДДДДДДДДЩіі методов. іі ЪДДДДДДДДБДДДДДДДДїіі Связи между этапами, идущие в об- іАДґОтладка и испыта-ііі ратном (по отношению к последователь- АДДґния опытн.образцаГЩі ности разработки) направлении, отражают АДДДДДДДДВДДДДДДДДЩ і возможность корректировки некоторых ре- ЪДДДДДДДДБДДДДДДДДї і шений, принятых на предшествующих эта- іИзготовл.и экспл.і і пах, по результатам анализа или иссле- іголовного образцаГДЩ дований, выполненных на последующих АДДДДДДДДВДДДДДДДДЩ этапах. ЪДДДДДДДДБДДДДДДДДї В рассмотренном порядке создания і Серийный і АЭИС находят отражение все системотех- і выпуск і нические принципы. Переход от общих АДДДДДДДДДДДДДДДДДЩ вопросов к частным, одновременная про-
работка отдельных подсистем и устройств, корректировка результатов
- эти и другие требования по порядку представляют собой основные
системотехнические концепции. я_Разработка технических предложенийя.: проводится изучение и
анализ предметной области в которой будет функционировать система
и формулируется общая постановка задачи ее создания. Цель создания системы формулируется как в виде конкретных
технических требований, так и виде некоторых общих положений. В функции разработчика на этом этапе входит: - разработка перечня работ по всем этапам обследования объ-
екта или исследования задач и формы представления необходимой ин-
формации; - методическое руководство всеми работами по обследованию
объекта или исследования задач, в т.ч. и работа совместно с
представителями заказчика; - анализ и обобщение материалов обследования (исследования). Заказчик обеспечивает сбор, систематизацию и представление
разработчику всей необходимой информации. На основе проведенной
работы проводится определение "общих контуров" проектируемой
АЭИС, выполняется ориентировочная оценка сроков ее создания и
приводятся расчеты стоимости и эффективности разработки. я_Разработка технических требований и технического задания
я_(ТЗ)я.. На основании рассмотренных технических предложений заказчик
формулирует ограничения для создаваемой системы, состоящие из це-
ли системы и принуждающих связей - факторов, ограничивающих выбор
способов достижения цели (иными словами, заказчик задает исходные
требования к системе, обусловленные ее назначением и условиями ее
создания или использования). ТЗ разрабатывается также на основе
результатов предпроектных НИР и экспериментальных работ, анализа
и прогнозирования передовых зарубежных и отечественных науч-
но-технических достижений. Согласование между заказчиком и исполнителем способов оценки
системы на начальной стадии ее создания является необходимым ус-
ловием для наиболее полного удовлетворения требований заказчика. На этом же этапе, при необходимости, между заказчиком и ис-
полнителем должны быть согласованы предложения, облегчающие проб-
лемы создания системы. Этап включает в себя подэтапы: я_Подэтап "Определение общих требований" Состав работ: неформальная постановка задачи, определение
функций АЭИС, обоснование необходимости проведения НИР; предвари-
тельный выбор методов и средств решения задач, критериев эффек-
тивности; моделирование наиболее важных функций и характеристик
АЭИС; предварительная декомпозиция АЭИС на комплексы; анализ ана-
логов АЭИС (по зарубежным и отечественным данным); анализ требо-
ваний ТТЗ на АЭИС на реализуемость и непротиворечивость; разра-
ботка требований к АЭИС; разработка требований к критериям, мето-
дам и средствам оценки качества системы; разработка требований к
порядку, видам и срокам испытаний и приемки АЭИС. Состояние АЭИС после этого подэтапа характеризуется выпуском
технических требований к информационной системе. я_Подэтап "Разработка ТЗ на АЭИС"я.. Помимо определения и форму-
лировки в ТЗ требований заказчика к АЭИС и условий ее эксплуата-
ции, установлен следующий порядок разработки: возможность приоб-
ретения или разработки тех или иных технических средств; возмож-
ность разработки соответствующего математического обеспечения
системы; сроки разработки подсистем и системы в целом, а также
распределение по указанным срокам финансовых ресурсов; мероприя-
тия по разработке управления системой; возможность использования
результатов в последующих разработках; технико-экономическое
обоснование (бизнес-план). Состав работ: формализация требований к техническим и прог-
раммным средствам системы; непосредственная разработка и оформле-
ние ТЗ; согласование и утверждение ТЗ на АЭИС. ТЗ оформляется заказчиком в виде документа, подписывается,
согласовывается и утверждается заказчиком и исполнителем в соот-
ветствии с установленным порядком. я_Разработка эскизного проектая.. Этап разработки эскизного проекта идет параллельно с эта-
пом эскизного проектирования АЭИС и включает подэтапы: я_Подэтап "Проработка архитектуры и декомпозиция АЭИС на комп-
я_лексы"я.. Основываясь на результатах обследования объекта или исс-
ледованиях задач, согласованных с заказчиком критериях, исполни-
тель определяет целесообразный уровень автоматизации процесса об-
работки экономической информации. Оценивая целесообразность авто-
матизации каждой из функций системы, исполнитель стремится перей-
ти от требований заказчика, ориентированных на назначение, к тре-
бованиям, ориентированным на техническое исполнение системы. При
этом вырабатывается схема системы, определяющая взаимоотношение
между людьми и аппаратурой; приводится в общем виде описание ал-
горитмов и процессов обработки информации; и документов, которые
предполагается использовать. Состав работ: определение оптимального соотношения аппарат-
ных и программных способов реализации автоматизируемых функций
системы; уточнение декомпозиции АЭИС на отдельные комплексы; исс-
ледование и апробация аналогов АЭИС; моделирования функций и ха-
рактеристик АЭИС; определение методов и средств организации
структур данных; проработка интерфейсов (внешних, пользователь-
ских, межкомплексных) по данным и управлению; уточнение требова-
ний АЭИС к вычислительным ресурсам; разработка уточненных требо-
ваний к АЭИС; составление внешней спецификации АЭИС на языке
функциональной спецификации. Состояние АЭИС после прохождения данного подэтапа характери-
зуется выпуском документов: уточненные технические требования к
АЭИС; внешняя функциональная спецификация комплексов АЭИС. На я_подэтапе "Разработка требований к операционной среде"
проводится анализ результатов моделирования характеристик и функ-
ций АЭИС, требований тактико-технического задания, внешних функ-
циональных спецификаций. Состав работ: разработка требований к конфигурации (П)ЭВМ и
сопроцессорным устройством (при необходимости); разработка част-
ного ТЗ на операционную среду или выбор и обоснование используе-
мой операционной системы. Состояние АЭИС после прохождения данного подэтапа: требова-
ния к конфигурации вычислительной техники; частное ТЗ на операци-
онную среду. я_На подэтапе "Проработка вопросов оценки и обеспечения ка-
я_чества АЭИС"я. разрабатываются (выбираются) методы оценок качества
системы и метрики для показателей качества АЭИС. Разрабатываются
частные ТЗ для проверки, отладки и испытаний АЭИС. Состав работ: разработка количественных показателей и мето-
дов оценки качества; разработка частных ТЗ на тесты для проверки,
отладки и испытаний системы и ее компонент, частных ТЗ на средс-
тва автоматизации испытаний. Состояние АЭИС после прохождения данного подэтапа: частное
ТЗ на разработку тестов; частное ТЗ на средства автоматизации ис-
пытаний АЭИС. я_На подэтапе "Разработка технико-экономического обоснования"
работы проводятся на основании утвержденных отраслевых методик
планирования разработки АЭИС определения трудоемкости работ. Состав работ: разработка экономической модели с учетом всего
жизненного цикла; проводятся ориентировочные расчеты трудозатрат,
времени и стоимости разработки; проводится оценка реальных сроков
разработки и имеющихся ресурсов; формируется укрупненный сквозной
график разработки. Состояние АЭИС после прохождения данного подэтапа характери-
зуется выпуском укрупненного графика разработки. я_Подэтап "Перспективное планирование создания системы" Состав работ: выбор и обоснование основных концепций техно-
логии разработки и состава технологического оборудования. разра-
ботка частного ТЗ на составные части ОКР и программирование; соз-
дание кооперации; разработка проекта руководящих указаний к раз-
работке; уточнение ТЗ на программные средства; разработка частно-
го ТЗ на тренажеры и обучающие средства; создание базы данных
программного проекта для автоматизации управления и контроля хода
разработки; разработка пояснительной записки к эскизному проекту. Состояние АЭИС после прохождения данного подэтапа характери-
зуется выпуском следующих документов: частное ТЗ на составные
части ОКР и ТЗ на программирование; руководящие указания к разра-
ботке; частные ТЗ на тренажеры и обучающие устройства. На этапе эскизного проектирования продолжается уточнение ор-
ганизационных вопросов: составляется общий сетевой график созда-
ния системы с учетом взаимодействия всех участвующих в разработке
организаций. В эскизном проекте может быть предложено несколько
вариантов решения задачи, проанализированы их достоинства и не-
достатки, выполнены оценки надежности. Производятся согласования всех связей проектируемой системы
с источниками и потребителями информации и исполнительными средс-
твами других систем. Эскизный проект рассматривается заказчиком,
его заключение с учетом согласованных замечаний является основой
для разработки технического проекта. я_Разработка технического проектая.. Этап технического проекти-
рования характеризуется более глубокой проработкой всех основных
частей АЭИС, причем, в отличие от эскизного проекта, где требует-
ся существование нескольких вариантов, в техническом проекте оп-
ределяются единственные решения основных вопросов. Все техничес-
кие решения системы должны быть согласованы технологически. Это
требование определяет уровень детализации проекта и степень конс-
трукторской проработки элементов системы. В некоторых случаях для
этого может потребоваться макетирование отдельных отдельных бло-
ков системы и их экспериментальное исследование. В итоге этой ра-
боты составляются технические условия (ТУ) на поставку системы. Математическое обеспечение на этапе технического проектиро-
вания должно быть полностью определено, т.е. разработаны струк-
турные схемы всех программ, программы решения всех основных за-
дач, проведена проверка все основных задач, разработаны програм-
мы, организующие работу всей системы, проработаны вопросы обеспе-
чения требуемой надежности. В составе технического проекта АЭИС должны быть следующие
разделы: описание общих принципов функционирования, общей струк-
туры системы с указанием подсистем; схема потоков информации с
указанием способов передачи информации; состав аппаратных
средств; технические условия на поставку системы; укрупненный
график разработки и внедрения АЭИС. Технический проект предусматривает "Постановку задачи" (или
"Исходные данные", в которую включаются: наименование задачи, ее
содержательная формулировка; данные о периодичности решения зада-
чи; связи данной задачи с другими задачами и ее место в комплексе
задач подсистем; описание способа организации сбора исходных дан-
ных и передачи их в память средств переработки информации; описа-
ние алгоритма решения задачи, точности решения, методов контроля
вычислений; расчет надежности; формулировка временных ограничений
на выдачу решения задачи; обоснование целесообразности предложен-
ного варианта задачи по сравнению с другими вариантами. Здесь же приводятся (в приложениях) описание форм входных
документов, форм промежуточных документов, сведения о представле-
нии информации, необходимой для связи с другими задачами. Разработанный технический проект АЭИС принимается комиссией,
назначаемой заказчиком. Решение комиссии с предложениями и заме-
чаниями утверждается заказчиком и является основой для рабочего
проектирования. я_Подэтап "Настройка инструментальных средств создания систе-
я_мы"я. характеризуется подготовкой технологической линии производс-
тва программ и "настройкой" инструментальных программных средств. Состав работ: настройка технологических средств; расчет ре-
сурсов и производительности технологической линии; доукомплекто-
вание технологической линии техническими и программными средства-
ми; уточнение план-графика разработки АЭИС. Состояние АЭИС после прохождения данного подэтапа характери-
зуется выпуском уточнений к графику разработки системы. На подэтапе я_"Декомпозиция системы на компоненты"я. осуществля-
ется очередной шаг в декомпозиции АЭИС до уровня компонент и мо-
дулей, проработка интерфейсов и структур данных. Основным резуль-
татом работ являются проектные спецификации, описанные на языке
функциональных спецификаций. Состав работ: декомпозиция системы на компоненты и модули;
определение функций и связи со смежными компонентами; определение
связей с внешними компонентами и операционной средой; разработка
интерфейсов и протоколов связи; разработка структур и докумен-
тальных форматов входных и выходных данных, методов организации и
доступа, способов кодирования и контроля; разработка внешней спе-
цификации компонент АЭИС на языке функциональных спецификаций;
детализация требований к ресурсам, параметрам, режимам использо-
вания вычислительной техники; контроль внешних спецификаций и
протоколов обмена, устранение ошибок; уточнение технических тре-
бований к АЭИС; уточнение требований к вычислительной технике,
сопроцессорным устройствам и к операционной среде; оценка качест-
ва проекта АЭИС; уточнение проектных спецификаций. Состояние АЭИС после прохождения данного этапа характеризу-
ется выпуском и корректировкой следующих документов: перечень
спецификаций компонент системы; уточнение технических требований
к системе; частное ТЗ на операционную среду; требования к вычис-
лительной технике и сопроцессорным устройствам На подэтапе я_"Разработка прототипа информационной системы"
осуществляется разработка внутренней спецификации компонент и мо-
дулей системы, разработка и верификация прототипа АЭИС. Цель раз-
работки прототипа - обеспечить раннюю диагностику ошибок проекти-
рования и предупредить их распространение на последующие стадии и
этапы. Прототип - это рабочая модель, функциональный эквивалент.
Верификация прототипа осуществляется его трансляцией, прогоном и
тестированием. Состав работ: детальная разработка структур и форматов дан-
ных; описание промежуточных данных, диагностических сообщений;
описание организации данных в памяти и машинных носителях. Выбор
программных средств управления данными; определение режимов рабо-
ты, условий выбора аппаратных и программных компонент, передачи
параметров, требований к вычислительным ресурсам; описание внут-
ренних спецификаций компонент и модулей АЭИС на языке функцио-
нальных спецификаций с учетом характеристик технических средств;
разработка прототипа АЭИС и имитатора модели внешней среды; испы-
тание прототипа АЭИС, корректировка внешних и внутренних специфи-
каций проекта АЭИС и прототипа; оценка качества проектирования
АЭИС; уточнение графика разработки АЭИС; уточнение требований к
вычислительным ресурсам; разработка уточненных требований к сос-
таву и срокам готовности тестов и средств автоматизации испытаний
и специализированных стендов реального оборудования; разработка
пояснительной записки к техническому проекту АЭИС; разработка,
испытание, передача в опытную эксплуатацию и сопровождение прог-
рамм, создаваемым по отдельным частным ТЗ. Состояние АЭИС после прохождения данного этапа характеризу-
ется выпуском следующих документов: пояснительная записка к тех-
ническому проекту; внутренние спецификации компонент и модулей. я_Разработка рабочего проектая. состоит в выпуске рабочей доку-
ментации, по которой изготавливается система, проводятся ее от-
ладка, испытания и передача в эксплуатацию. Разрабатываются рабо-
чие программы и инструкции по их использованию и изменению. Вы-
полняются решения, принятые на стадии технического проектирова-
ния. Практически этот этап состоит из двух разделов: - я_изготовление рабочих чертежейя. (рабочей документации) в ко-
торой входят: машинные алгоритмы и программы решения задач, инс-
трукции по их эксплуатации; инструкции по подготовке исходных
данных для решения задач и по использованию полученных результа-
тов; должностные инструкции; рабочая документация на размещение,
установку и монтаж аппаратных средств; инструкции по эксплуата-
ции. После проведения предварительных испытаний и устранения вы-
явленных недостатков проводится корректировка рабочей документа-
ции. Рабочая документация практически создается в процессе всей
разработки рабочего проекта. - я_создания.ея_ опытного образца системыя. (обычно на стенде, на
котором проводится комплексная стыковка и отладка, здесь же про-
веряется соответствие системы заданным в ТЗ характеристикам).
Опытный образец поступает на испытания, которые проводятся ве-
домственной комиссией в соответствии методикой (программой), сог-
ласованной и утвержденной исполнителем и заказчиком. Создание опытного образца системы включает в себя подэтапы: я_Подэтап "Разработка компонент системы"я.. Параллельно с разра-
боткой аппаратных и программных модулей, а также программ-компо-
нент системы на подэтапе создаются инструментальные программные
средства тестирования и имитаторы для автономной и комплексной
отладки АЭИС. Проводится цикл уточнения спецификаций. Выпускается
техническая и программная документация на различные компоненты. Состав работ: разработка детального графика кодирования,
компоновки, документирования, испытания компонентов системы; раз-
работка средств тестирования и программных имитаторов для авто-
номной и комплексной отладки; разработка тестовых примеров и до-
кументов; разработка (и тиражирование) аппаратных и программных
модулей, программ-компонент; автономная отладка; тестирование
программ-компонент; уточнение проектных спецификаций; документи-
рование аппаратных и программных модулей и программ-компонент;
оценка качества аппаратных и программных модулей и программ-ком-
понент; разработка, испытание, передача в опытную эксплуатацию и
сопровождение компонентов, создаваемым по отдельным частным ТЗ. Состояние АЭИС после этого характеризуется выпуском докумен-
тов: программная документация на тесты; паспорта автономной от-
ладки аппаратных и программных модулей; техническая и программная
документация на аппаратные и программные модули. я_Подэтап "Отладка комплексов системы"я. проводится непосредс-
твенно на предприятиях-соисполнителях. Паспорта комплексной от-
ладки предъявляются головному исполнителю. На подэтапе проводится
проверка готовности специализированного стенда отладки и испыта-
ний программных средств системы. Проверка готовности технических
средств осуществляется по специальным тестам бригадой программис-
тов из состава разработчиков системы. Состав работ: разработка детального (сетевого) графика комп-
лексной отладки; компановка комплексов системы; подготовка тесто-
вых примеров; отладка комплексов системы в статическом режиме;
отладка комплексов системы в динамическом (квазиреальном) режиме;
проверка готовности специализированного стенда отладки и испыта-
ния АЭИС; отладка комплексов системы в реальном масштабе времени;
оценка качества комплексов системы; выпуск технической и прог-
раммной документации на комплексы системы; разработка технических
условий; разработка, испытания, передача в опытную эксплуатацию и
сопровождение системы, создаваемой по отдельным частным ТЗ. Состояние АЭИС после этого характеризуется выпуском докумен-
тов: паспорт комплексной отладки; программная документация на
комплексы системы; проект технических условий. я_Подэтап "Расширенное тестирование комплексов системы"я.. На
подэтапе проводится интенсивная работа по локализации и исправле-
нию ошибок в программах. Полнота охвата ветвей программ контроль-
ными примерами оценивается по паспортам испытаний системы. При
обнаружении принципиальных отклонений в программах уточняются
спецификации и технические требования. Программы компоненты и программные комплексы с технической и
программной документацией передаются на ответственное хранение в
службу ведения алгоритмов и программ головного разработчика. Из-
менения вносятся в порядке, установленном в подразделении, веду-
щем фонд алгоритмов и программ. Состав работ: разработка методики и графика тестирования;
подготовка тестовых примеров и исходных данных с участием заказ-
чика; тестирование аппаратных и программных комплексов, оценка
полноты контрольных примеров; уточнение спецификаций и техничес-
ких требований; устранение ошибок; корректировка системы, техни-
ческой и программной документации по результатам тестирования;
оценка качества комплексов аппаратных и программных средств; пе-
редача промышленного образца системы, технической и программной
документации головному разработчику. Состояние АЭИС после этого характеризуется выпуском или кор-
ректировкой документов: журнал тестирования и испытаний; журнал
корректировок и модернизации; проектные спецификации аппаратных и
программных компонентов системы; внутренние спецификации компо-
нент и модулей системы; технические требования к системе. я_Подэтап "Проведение стендовых испытаний опытного образца
я_системы"я.. Стендовые испытания проводятся в соответствии с прог-
раммой и методикой испытаний, согласованной с заказчиком. Испыта-
ния системы проводятся на специализированном стенде, включающем в
свой состав объектные ЭВМ и основные типы переферийных устройств
системы. Процесс проведения стендовых испытаний предусматривает
оперативное устранение ошибок, уточнение технических требований и
спецификаций АЭИС. На подэтапе проводится компоновка по всем
комплексам для отдельных элементов системы. Состав работ: разработка программы и методики стендовых ис-
пытаний системы и графика испытаний; проведение стендовых испыта-
ний; ведение журнала испытаний; коррекция аппаратных и программ-
ных компонентов, а также технической и программной документации;
уточнение технических требований и спецификаций; компоновка сос-
тавных частей системы; предварительная оценка выполнения системой
тактико-технических требований; подготовка заключения; внесение
изменений в техническое и программное обеспечение системы, а так-
же техническую и программную документацию через службу ведения
фонда алгоритмов и программ головного разработчика; разработка,
испытание, передача в опытную эксплуатацию и сопровождение сис-
тем, создаваемых по отдельным частным ТЗ. Состояние АЭИС после этого характеризуется выпуском или кор-
ректировкой документов: журнал тестирования и испытаний; журнал
корректировок и модернизации; технические требования; проектные
спецификации и внутренние спецификации компонент и модулей. я_Подэтап "Проведение предварительных испытаний системы"я. явля-
ется заключительным на этапе рабочего проектирования. Предвари-
тельные испытания системы и ее компонент проводятся на фрагменте
системы, технические средства которой оговариваются в программе и
методике испытаний. В процессе испытаний могут быть использованы
дополнительные технические и программные средства имитации "окру-
жения". На подэтапе обеспечивается подготовка должных лиц системы
от заказчика к самостоятельной работе. Состав работ: разработка программы и методики испытаний сис-
темы и графика испытаний; укомплектование системы носителями и
программной документацией; подготовка совместно с заказчиком
контрольных примеров; тестирование вычислительной техники и тех-
нических средств; проведение испытаний; устранение ошибок, уточ-
нение технических требований и спецификаций, корректировка прог-
раммной документации; подготовка заключения о готовности АЭИС к
работе; обучение должностных лиц системы работе с АЭИС при испы-
таниях; сопровождение АЭИС при предварительных испытаниях систе-
мы; разработка, испытание, передача в опытную эксплуатацию и соп-
ровождение систем, создаваемых по отдельным частным ТЗ. Состояние АЭИС после этого характеризуется выпуском или кор-
ректировкой документов: акт предварительных испытаний; техничес-
кая и программная документация на компоненты системы; программная
документация на тесты; документация на комплексы программ. После этого этап технического проектирования завершается и
затем последовательно осуществляется: - я_опытная эксплуатация и доработка головного образцая.; - я_корректировка документациия.; - я_выпуск и ввод в эксплуатацию серийных образцовя.. 3. Организация проектирования автоматизированных экономичес-
ких информационных систем; принципы планирования разработки АЭИС
(15.1.). Своеобразие информационных систем (и в частности АЭИС), как
продукции производственно-технического назначения, выражающееся в
ее сложности, в отсутствии нормативов на большинство видов проце-
дур и работ, делает процесс их планирования и проектирования (а
также производства) весьма сложным и затруднительным. Для управления и осуществления планирования проектом необхо-
дима организационная структура, которая детализирует порядок про-
ведения работ. Она определяет взаимодействие компонентов системы
проектирования в соответствии с иерархией проводимых работ. Особенно важна четкая организационная поддержка во всем жиз-
ненном цикле сложных АЭИС систем управления. В этом случае регла-
ментирование коллективного труда большого коллектива специалистов
и взаимодействия руководителей проекта с заказчиком и пользовате-
лями может практически полностью определять успех всего жизненно-
го цикла АЭИС. Значительная часть работ в жизненном циле сложных информаци-
онных систем связана с исследованием и разработкой методов управ-
ления информацией. Организация проектирования охватывает следую-
щие основные этапы. 1. СИСТЕМНЫЙ АНАЛИЗ И ПРОЕКТИВАНИЕ АЛГОРИТМОВ (определение
целей системы; выбор методов решения задач; проектирование алго-
ритмов; разработка технического задания на АЭИС) 2. СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ (определение структуры АЭИС;
определение структуры модулей; распределение производительности
ЭВМ; распределение памяти ЭВМ) 3. ПОДГОТОВКА ТЕХНОЛОГИЧЕСКИХ СРЕДСТВ (организация БД проек-
та; адаптация языков программирования; настройка средств трансля-
ции и отладки; разработка инструкций для применения технологии) 4. ПРОЕКТИРОВАНИЕ ТЕХНИЧЕСКИХ СРЕДСТВ 5. РАЗРАБОТКА ПРОГРАММНЫХ СРЕДСТВ (разработка спецификаций
на модули и группы программ; трансляция глобальных переменных;
трансляция текстов программ; загрузка программ и редактирование
связей) 6. ОТЛАДКА СИСТЕМЫ В СТАТИКЕ (планирование отладки системы;
тестирование системы; локализация ошибок и корректировка систем;
комплексирование систем) 7. КОМПЛЕКСНАЯ ДИНАМИЧЕСКАЯ ОТЛАДКА (выбор средств для ими-
тации абонентов; разработка программ имтации; создание программ
обработки результатов; отладка функционирования АЭИС в реальном
масштабе времени) 8. ВЫПУСК МАШИННЫХ НОСИТЕЛЕЙ И ДОКУМЕНТИРОВАНИЕ (изготовле-
ние машинных носителей; изготовление эксплуатационных документов;
изготовление технологических документов; изготовление исследова-
тельских документов) 9. ИСПЫТАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ (испытания на полноту
функционирования; испытания на надежность функционирования; обра-
ботка результатов испытаний; разработка акта испытания) В настоящее время я_я2процесс планированияя.я0 выполняется ведущими
специалистами на базе уже имеющегося опыта разработки аналогичных
систем (под планированием понимается процесс уточнения состава и
порядка действий, процедур и работ, обеспечивающих создание ин-
формационной системы с заданными свойствами при одновременном оп-
ределении сроков выполнения отдельных этапов и стадий разработки
с целью получения необходимого изделия по возможности с минималь-
ными затратами и в установленные сроки). Более сложная проблема возникает при разработке информацион-
ной системы кооперацией соисполнителей, в том числе территориаль-
но разрозненных. В этом случае планирование представляет собой
итерактивный процесс, включающий в себя два основных этапа. На первом этапе головной исполнитель, владея директивными
сроками на создание АЭИС в целом, определяет состав кооперации по
отдельным видам работ, устанавливает на основе экспертных оценок
трудоемкости работ и задает сроки выполнения работ таким образом,
чтобы выполнить заданные директивные сроки выполнения всей работы. На втором этапе планирование выполняется каждым соисполните-
лем, исходя из заданных сроков выполнения работ. Происходит уточ-
нение объемов работ и формирование коллектива разработчиков для
выполнения заданного объема работ. Существуют подходы, позволяющие автоматизировать процесс
планирования и управления разработкой АЭИС, из которых наибольше-
го внимания заслуживает программно-целевой метод, для которого
характерно распределение ресурсов не на решение отдельных задач,
а на достижение основных целей. Конкретные цели и срок всей раз-
работки, их взаимоувязка на основе способствует реализации разра-
ботки АЭИС. В общем виде АЭИС можно разбить на подсистемы, прог-
раммы и программные модули. Система целей соответствует дереву
целей, в котором фиксируется генеральная цель. Планирование проектирования АЭИС может также базироваться на
я_я2долгосрочном прогнозированиия.я0 их состояния в целом и основных ком-
понент, на прогнозировании изменения характеристик качества, на
оценках развития обнаружения и устранения ошибок. Долгосрочный план проектирования должен содержать: 1. я2Формулировку общих целей АЭИС и и частных целей создания
я2ее компонент.я0 Проводится в техническом задании с указанием харак-
теристик АЭИС, которые должны быть получены при ее создании. Эта
часть расширяется оценками влияния основных факторов на эффектив-
ностьрешения основной целевой задачи. 2.я2 Стратегию проведения проея0кя2тирования.я0 Обеспечивает выпол-
нение поставленных перед АЭИС как общих, так и частных целевых
задач с минимальными затратами или минимальными сроками. Она
должна определять: принципы и этапы проведения проектирования;
последовательность и длительность разработки и отладки структурно
и функционально законченных групп аппаратных и программных
средств; перечень и объем вспомогательных работ, направленных на
ускорение и повышение качества разработки. 3. я2Потребности в ресурсах различных видов для проведения
я2проектирования. 4. я2Проект организационной структуры коллектива, необходимого
я2для проведения работ. 5. я2Проект технологии и управления всем процессом проведения
я2работ и координации их взаимодействия. Особенность сетевого планирования разработки сложных АЭИС
состоит в неопределенности интервалов длительности выполнения ря-
да работ. Это обусловлено переплетением процессов технического
проектирования и исследований отдельных функциональных алгоритмов,
а также отработкой методов решения задач. Для построения я_я2сетевого графикая.я0 предлагается перечень основ-
ных событий. 1. я1Откорректировано и утверждено заказчиком техническое за-
я1дание. 2. я1Откорректирован состав частных задач групп программ и
я1осуществлен выбор методов их решенияя0, что фиксируется в обобщаю-
щем документе (спецификации требований), являющемся неофициальным
расширением и уточнением технического задания. 3. я1Разработана функциональная схема АЭИСя0, определяющая ук-
рупненную логику обработки информации и функционирование всей
системы, а также организацию решения всех функциональных задач,
основные логические и информационные связи между группами прог-
рамм, решающими частные задачи, взаимодействие с внешними абонен-
тами по обмену информацией. 4. я1Разработаны частные технические задания и предварительные
я1варианты групп программя0, фиксирующие назначение, методы решения и
состав обменной информации для каждой из разрабатываемой групп
программ. При разработке детального сетевого графика необходимо
эти этапы распараллеливать по числу функционально законченных
частей АЭИС и выделять наиболее трудоемкую и длительную по срокам
разработки часть, определяющую критический путь. 5. я1Разработано описание глобальных переменныхя0, в котором да-
ется строго формализованное описание каждой информационной связи
между программами, подробно и точно расшифровываются их признаки
и спецификации данных, а также отмечаются имена программ, форми-
рующих и использующих такие переменные. 6. я1Уточнена технологическая схема проведения разработки АЭИС
с использованием средств автоматизации, в которой особое внимание
должно уделяться полноте и комплексному использованию этих
средств. 7. я1Произведено оценочное программирование я0для оптимизации
использования ресурсов ПЭВМ, для уточнения затрат на решение от-
дельных задач, а также для распределения производительности и па-
мяти команд. 8. я1Произведена оценка потоков сообщений и заявок, длитель-
я1ностей решений и допустимых запаздываний в решении частных задач
путем анализа параметров источников сообщений, по затратам на ре-
шение аналогичных задач, а также в результате экспертного опроса
ведущих специалистов. 9. я1Разработано распределение оперативной памяти я0исходя из
требований к допустимой вероятности потери сообщений, из функцио-
нальных требований АЭИС, а также из ограничений на общий объем
оперативной памяти. 10. я1Рассчитаны основные характеристики возможных схем органи-
я1зации вычислительного процесса я0и определена их эффективность, в
результате чего подготавливаются варианты схемы организации вы-
числительного процесса, которые дополнительно проверяются на сте-
пень выполнения ряда технических и идеолоя1гя0ических ограничений си-
стемы управления или обработки информации. 11. я1Рассчитаны основные характеристики вариантов схем опера-
я1тивного контроля вычислительного процесса я0для обеспечения надеж-
ности решения при наличии искажений исходной информации, сбоев
ПЭВМ и невыявленных ошибок в программах. 12. я1Разработано распределение памяти команд и константя0, кото-
рое должно обеспечивать реализацию АЭИС, "равнопрочного" по ка-
честву всех решаемых задач в условиях ограниченных ресурсов ПЭВМ. 13. я1Разработаны функциональная схема организации вычислитель-
я1ного процесса я0и алгоритмы взаимодействия с внешними абонентами,
алгоритмы начального пуска, центрального диспетчера, местных дис-
петчеров, временной тактировки и т.д. 14. я1Разработаны функциональная схема оперативного контроля и
я1обеспечения надежности вычислительного процесса, я0алгоритмы сбора
данных об искажениях вычислительного процесса и алгоритмы приня-
тия решений в зависимости от характеристик выявленных искажений. 15. я1Произведена оценка необходимой производительности реали-
я1зующей ПЭВМ, я0а также выявлены задачи, требующие большего времени
для решения. 16. я1Аналитически уточнены основные характеристики выбранных
я1методов решения задачя0: точностные характеристики, эффективность,
пропускная и разрешающая способность, устойчивость алгоритмов уп-
равления и т.д. 17. я1Методом моделирования уточнены характеристики выбранных
я1алгоритмов решения задачя0, которые сопоставлены с аналитическими
исследованиями и представлены как часть пояснительной записки к
техническому проекту. 18. я1Определены требования к средствам автоматизации проекти-
я1рования и языку программированияя0, которые позволяют создавать и
отлаживать программы при допустимых затратах труда и при доста-
точно эффективном использовании ресурсов реализующей ПЭВМ. 19. я1Уточнен выбор реализующей ПЭВМ я0с учетом необходимой опе-
ративной памяти, памяти команд и производительности, а также ме-
тодов организации вычислительного процесса и обеспечения надеж-
ности решения задач. 20. я1Подготовлены предложения по уточнению технического зада-
я1ния на АЭИС я0с учетом выбранных методов решения задач, параметров
ПЭВМ, сроков разработки , квалификации специалистов, принятой
технологии проектирования и т.д. 21. я1Определен состав и форма технической документации на ап-
я1паратные и программные средствая0, которые согласуются с заказчиком
и и формализуются в стандарте предприятия. 22. я1Разработана или выбрана система автоматизации проектиро-
я1ванияя0, которая должна быть рентабельной, т.е. затраты времени и
средств на ее разработку или освоение должны окупаться сокращени-
ем времени и затрат при создании АЭИС. 23. я1Разработан и предъявлен заказчику технический проект
я1АЭИС, я0в котором представлен макетный образец системы и ее доста-
точно полные функциональные и технические характеристики. В зависимости от глубины исследований и и инженерных разра-
боток алгоритмов в той области, где предполагается применять
АЭИС, критический путь сетевого графика может проходить либо по
работам, носящим исследовательский и методический характер (1
группа), либо по работам, обеспечивающим непосредственное созда-
ние программ (2 группа), либо по работам, связанным с созданием
технологических средств автоматизации программирования и отладки
программ (3 группа). ЪДДї ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДґ17ГДДДДДДДДДДДДї
1 группаі АДДЩ і
работ і ЪДДї і іЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДґ16ГДДДДДДДДДДДїі іі АДДЩ іі
--------іі-----------------------------------------------іі-------- іі ЪДДї ЪДДї іі
2 группаіі ЪДДДДДДДДґ11ГДДДґ14і іі
работ іі і АДДЩ АДВЩ іі іі ЪБДї ЪДДї ЪДДї і іі іі ЪДДґ 8ГДДДґ10ГДДДґ13Гїі іі іі і АДДЩ АДДЩ АДДЩіі іі
ЪДДї ЪББї ЪДДї ЪБДї ЪДДї ЪДДї ЪББї ЪДДї ЪББї ЪДДї
1ГДДДґ 2ГДДДґ 3ГДДДґ 4ГДДДґ 7ГДДДґ12ГДДДґ15ГДДДґ19ГДДДґ20ГДДДґ23і
АДДЩ АВДЩ АВДЩ АДДЩ АДДЩ АДДЩ АВВЩ АДДЩ АДДЩ АВВЩ і і ЪДДї ЪДДї іі ЪДДї іі і АДДДДДґ 5ГДДДДДДДґ 9ГДДДДДДДЩАДДДДДДДДДДДґ21ГДДДДЩі і АДДЩ АДДЩ АДДЩ і
--------і--------------------------------------------------------і-
3 группаі ЪДДї ЪДДї ЪДДї і
работ АДДДДДДДДДДДДґ 6ГДДДДДДДДДДДДДДДДДґ18ГДДДДДДДДДДґ22ГДДДДДЩ АДДЩ АДДЩ АДДЩ Критический путь сетевых графиков не всегда проходит по со-
бытиям непосредственного создания программ Следует отметить, что в зависимости от глубины исследований и
и инженерных разработок алгоритмов в той области алгоритмов в той
области, где предполагается применять АЭИС, критический путь се-
тевого графика может проходить либо по работам, носящим исследо-
вательский и методический характер (1 группа), либо по работам,
обеспечивающим непосредственное создание программ (2 группа), ли-
бо по работам, связанным с созданием технологических средств ав-
томатизации программирования и отладки программ (3 группа). я_я2Организация коллективов для создания АЭИСя.я0. Конец 70-х годов
характеризовался за рубежом как кризис в области создания и про-
ектирования информационных систем в части программного обеспече-
ния, который заключался в отставании технологии разработки прог-
рамм и производства аппаратной части вычислительной техники. Ос-
новными причинами отставания качества проектирования систем явля-
лись: низкое качество планирования процесса разработки отдельных
компонент и всей системы для заданной цели; плохое управление
коллективами специалистов, ведущих разработку, и недостаточный
контроль за объективным состоянием систем. Быстрое раширение круга специалистов, участвующих в разра-
ботке систем, приводит к необходимости индустриализации проекти-
рования и создания технологических процессов разработки послед-
них. Организация коллектива и распределение работ по специалистам
могут осуществляться по следующим принципам: на основе распреде-
ления системного анализа (алгоритмизации) и равзработки компонен-
тов системы по разным коллективам; по принципу выделения коллек-
тивов, создающих всю совокупность программных модулей, и группы
специалистов, объединяющих эти компоненты в единый комплекс; по
принципу распределения достаточно сложных законченных функцио-
нальных задач по группам специалистов, осуществляюшим их полную
разработку, и последующего объединения функциональных задач спе-
циальной группой ведущих "комплексников". Одним из вариантов организационной структуры коллектива при
создании крупных АЭИС является иерахическая структура, базирующа-
яся на группах (из 7-10 человек) специалистов разной квалифика-
ции, решающих достаточно автономную функциональную задачу. 4. Виды поддержки процесса проектирования автоматизированных
информационных систем (АЭИС); документирование; цели проектирова-
ния АЭИС (32.1.). я_я2Методологическая поддержкая.я0 включает набор стандартов, инс-
трукций и методик, определяющих правила создания систем и регла-
ментирующие построение объекта разработки и процесса его созда-
ния. В методиках и инструкциях конкретизируются языки проектиро-
вания систем, правила использования символов и обозначений, пра-
вила структурного построения аппаратных и программных компонент и
их взаимодействия и другие важнейшие методические принципы орга-
низации вычислительных и информационных систем. Сюда могут быть
отнесены и документы, содержащие методические основы процесса со-
здания систем: правила программирования, принцыпы отладки компо-
нент систем, порядок их испытания, способы оценки качества и т.д. На базе государственных и отраслевых стандартов, содержащих
методические основы проектирования систем, для разработки конк-
ретной АЭИС или группы систем одного класса создаются стандарты
предприятия и руководящие указания по проектированию. В совокуп-
ности эти документы отражают отражают различные аспекты методоло-
гии создания конкретных АЭИС. я_я2Технологическая поддержкая.я0 детализирует документы методологи-
ческой поддержки, регламентирующие технологию обеспечения жизнен-
ного цикла систем. Документы технологической поддержки определяют
этапы проектирования, их результаты и методы контроля соблюдения
предписанной технологии. Они тесно связаны с технологией эксплуа-
тации и сопровождения систем. Технология формализует методы и
критерии оценки количества и качества информационной системы
(программного продукта) на различных этапах его создания. Для
каждого этапа создания аппаратной и программной компонент АЭИС
регламентируются: допустимая трудоемкость; длительность его вы-
полнения с учетом параметрических характеристик объекта разработ-
ки. В технологии создания конкретных АЭИС определяется использо-
вание инструментальных средств автоматизации разработки системы.
Для каждого средства автоматизации рекомендуется область его эф-
фективного применения и взаимодействия с другими средствами. В конечном итоге технологический процесс представляется ме-
тодами, документами и инструментальными средствами автоматизации,
в совокупности обеспечивающими необходимое качество системы при
допустимых затратах различных ресурсов на их создание. я_я2Инструментальная поддержкая.я0 состоит из программных средств и
средств вычислительной техники, связи и тиражирования, обеспечи-
вающих автоматизацию процесса создания АЭИС (комплекса программ). я_я3Программная оснащенностья.я0 определяется функциональными воз-
можностями программных систем автоматизации разработки ПО. Для
каждого этапа разработки могут применяться методы и средства,
различающиеся эффективностью, в свою очередь зависящей от особен-
ностей проектируемой АЭИС. В первом приближении степень программ-
ной оснащенности можно охарактеризовать объемом программ, активно
используемых в типовой технологии. При этом используются следую-
щие средства: трансляции программных спецификаций и текстов прог-
рамм с языков высокого уровня; планирования и контроля статичес-
кого и динамического тестирования программ; программного модели-
рования объектов внешней среды; автоматизированного управления
разработкой и конфигурационного контроля ПС. я_я2Аппаратурная оснащенностья0 я.разработки сложных систем опреде-
ляется мощностью используемых ЭВМ и возможностью доступа к ним, а
именно: быстродействием ЭВМ, используемых при разработке; - чис-
лом дисплеев, сопряженных с различными типами ЭВМ, доступных в
среднем каждому разработчику программ; средним числом возможных
подходов к ЭВМ для реализации технологических операций каждым
разработчиком за рабочий день. Значительное улучшение всех пока-
зателей аппаратурной оснащенности достигается при использовании
профессиональных персональных ЭВМ в автономном режиме и в локаль-
ных сетях совместно с большими ЭВМ. В качестве средств проектиро-
вания или инструментария проектировщика при использовании ПЭВМ
должны применяться средства: ведения индивидуальной базы данных
(СУБД и окружение); интерфейса пользователя (электронные таблицы,
подсказка, графика, меню); информационного поиска (фактографичес-
кого и смыслового); текстового редактирования (обработка и разме-
щение текста, использование разнообразных шрифтов, электронная
почта; программирования; простейших вычислений (калькулятор); ка-
лендаризации (электронный календарь и блокноты) и др. я_я2Организационную поддержкуя.я0 составляют документы, регламенти-
рующие взаимодействие специалистов внутри коллектива разработчи-
ков и с соисполнителями, а также с заказчиками и пользователями.
Они определяют права, обязанности и меру ответственности специа-
листов и руководителей с учетом их должности и квалификации. На
эти организационные положения и распределение их по специалистам
влияют методологические и технологические принципы распределения,
а также характеристики объекта и этапов разработки. Одним из наиболее важных факторов качественного проектирова-
ния систем является четко организованная, легко читаемая и усваи-
ваемая я_я2документацияя.я0, сжатая, но полная, допускающая внесение из-
менений. Документация на сложные АЭИС предназначена для детально-
го отображения их содержания и специфики в процессе разработки,
отладки, изготовления, эксплуатации и сопровождения. Продвигаясь в рамках цикла проектирования от требований
пользователей и функциональной спецификации к объединению и оцен-
ке действующей системы, можно определить, какая информация должна
быть включена в документацию на каждом уровне проектирпования и
построения системы. Для полного цикла проектирования целесообраз-
но выделить следующие уровни. 1. я_Требования пользователей и функциональные спецификациия..
Этот уровень содержит информацию, необходимую для оценки функцио-
нирования системы. Рациональным является разработка на этом этапе
я_руководства пользователя я.или я_руководства операторая., в которых
описывается работа системы. (Следует отметить, что принято разра-
батывать этот документ в конце цикла проектирования, и часто
воспринимается какя_ неизбежное злоя..) 2. я_Проектная документация системыя.. Сюда включаются проектные
спецификации программного обеспечения, а также описания процедур,
модулей и подсистем на языке проектирования. Обязательной являет-
ся следующая информация: идентификационные номера процедур и мо-
дулей; имя проектировщика каждой процедуры и модуля; дата проек-
тирования процедуры или модуля; именя всех, кто вносил изменения
в проект; даты внесения изменений в проект; краткий сведения о
том, что делают процедура или модуль; имя модуля, которому при
надлежит процедура описание структуры данных и параметров, кото-
рые обрабатываются данной процедурой; пояснения о назначении каж-
дого параметра в структуре данных, если это неясно из контекста. 3. я_Программная документацияя.. Состоит из описания процедур и
и модулей системы в виде программ на языке программирования. 4. я_План объединенияя.. Состоит преимущественно из информации
для руководства проектом (включает схемы руководства календарными
сроками проекта. 5. я_Техническая документацияя.. Содержит функциональные описа-
ния аппаратных средств 6.я_ План отладки аппаратных средств я_я2ЦЕЛИ ПРОЕКТИРОВАНИЯя.я0. я_я2Качество АЭИС: учет человеческих факторовя.я0 я_Легкость использованияя. означает такую разработку документа-
ции, средств управления структур и форматов входных и выходных
данных, которая делает систему удобной, естественной и гибкой. я_Удовлетворение потребностей пользователей я.означает учет тех
требований относительно информации или вычислительных средств,
для выполнения которых предназначено АЭИС. я_Реализация потенциальных способностей пользователя я.означает
обеспечение более творческого характера труда и большего удовлет-
ворения своей работой пользователей, эксплуатирующих АЭИС. я_Следование модифицированному золотому правилу.я. Это правило
гласит: "Относитесь к другим людям также, ка Вы хотели бы, чтобы
относились к Вам будь Вы на месте этих людей". В проектировании
информационных систем одной самых больших ошибок следование (но с
весьма неудовлетворительными результатами) немодифицированному
золотому правилу:
Относитесь к другим і Разрабатывайте информационные системы, с ко-
людям, как Вы хоте- і торыми будут работать пользователи и опера-
ли бы, чтобы отно- і торы, предполагая, что они любят программи-
сились к Вам. і ровать и сведущи в вычислительной технике В области системотехники (многоразрядные ЭВМ, операционные
системы и т.п.), которая в значительной степени является сферой
деятельности университетских кафедр вычислительной науки, это
вполне допустимо, т.к. пользователями компиляторов и операционных
систем являются программисты, которые весьма сведущи в вопросах,
связанных с вычислительной техникой. Но это предположение неверно
в области прикладных ИС, где типичными пользователями и операто-
рами являются экономисты, статистики, бухгалтеры, нормировщики,
финансисты, кассиры и т.п. Они, как правило не сведущи в програм-
мировании и вычислительной технике и при использовании разрабо-
танных для них систем гораздо больше озабочены использованием
своих профессиональных возможностей. я_я2Качество АЭИС: управление ресурсами я_Эффективность я.означает, что ИС выполняет свои функции без
излишних затрат ресурсов. К ресурсам относятся все средства, за-
пасы и другие величины, объем которых ограничен: денежные ресур-
сы, время разработки, машинное время, оперативная память, про-
пускная способность канала передачи данных и т.п. я_Измеряемость я.означает, ИС, как готовое изделие, можно оснас-
тить контрольно-измерительными средствами и замерить его характе-
ристики для определения "узких мест" и неэффективности системы, а
также можно легко модифицировать эти средства или настроить их
для учета изменений. я_я2Качество АЭИС: Программотехникая.я0 я_Специфированность я.означает, что до начала разработки системы
тщательно и недвусмысленно специфированы функциональные, техни-
ческие и интерфейсные требования на ИС. Это вовсе не обязывает
разработчиков воздерживаться от программирования до полного окон-
чания спецификации требований. Основными характеристиками специ-
фированности являются следующие: 1) я_полнотая.: спецификация является полной, если в ней при-
сутствуют все необходимые части, и каждая часть разработана над-
лежащим образом; 2) я_безопасностья.: спецификация учитывает требования безопас-
ности, если в ней четко определено функционирование ИС для всех
нештатных условий; конструктивным методом достижения безопасности
является подход, основанный на преобразовании предикатов. 3) я_непротиворечивостья.: спецификация непротиворечива, если
если ее положения не противоречат друг другу или другим главным
спецификациям или целям; 4) я_осуществимостья.: спецификация осуществима, если в течение
всего жизненного цикла специфицированной системы обеспечивается
возмещение затрат и прибыль; 5) я_проверяемостья.: спецификация проверяема, если разработан-
ная ИС может быть подвергнута проверке на соответствие положениям
этой спецификации. я_Правильность я.означает, что ИС строго строго соответствует
всем функциональным и интерфейсным спецификациям, а также удов-
летворяет в пределах допусков всем спецификациям технических ха-
рактеристик. я_Адаптируемость я.означает, что готовая ИС или ее компоненты
можно легко использовать или приспособить для выполнения новых
функций. Адаптируемость включает в себя: 1) я_модифицируемость я.-
изделие способствует простоте внесения изменений; 2) я_переноси-
я_мость я.- изделие может легко и хорошо эксплуатироваться в новых
конфигурациях СВТ; 3) я_работоспособность я.в других системах - изде-
лие или его компоненты могут использоваться в качестве компонен-
тов других систем. Основными характеристиками адаптируемости являются следующие: я2структурированностья0: информационная система структурирована,
если она построена по следующим принципам: - я1абстракцияя0: изделие организовано в виде иерархии "уровней
абстракции", каждый из которых не содержит информации о свойствах
нижних уровней и скрывает информацию о своих внутренних свойствах
от более высоких уровней; я1модульностья0: изделие составлено из небольших и независимых
модулей, каждый из которых состоит из сильно связанных между со-
бой частей; я1минимальное число примитивовя0: число видов компонентов, из
которых построено изделие, минимально (например, в качестве уп-
равляющих структур используются только составные операторы:
if-then-else, case, do-while, do-until и undo); следует отметить,
что принципы структурированности относятся не только к програм-
мам, но и к данным и к документации; я2независимостья0: ИС независима,если на ее работу не влияют из-
менения в устройствах, используемых при функционировании (напри-
мер, изменения в операционных системах и системах управления БД); я2понятностья0: ИС является понятной, если ее назначение и функ-
ционирование ясны специалистам, которые должны с ней работать. я_я2Эфективность процесса разработки АЭИС: учет человеческих
я_я2факторовя.я0 Целью учета человеческих факторов является такое управ-
ление занятыми в процессе сотрудниками, которое позволит удовлет-
ворить их запросы и реализовать их творческий потенциал. я_Планируемость я.предполагает разработку и непрерывное поддер-
жание в рабочем состоянии плана проектирования изделия. В плане
указываются: причины, по которым предпринята разработка проекта;
сроки достижения результатов; ответственные за достижение резуль-
татов; способы достижения результатов; необходимые ресурсы; пред-
положения, на основе которых должны быть получены результаты. я_Организованность я.предполагает разработку и непрерывное под-
держание некоторой структуры должностей и обязанностей. Главными
элементами организованности являются: передача прав и ответствен-
ности подчиненному; разделение труда. Некоторые принципы органи-
зованности аналогичны принципам структурированности ИС (например,
модульность и скрытность информации). Это выражено в законе
"Струтура ИС однозначно соответствует структуре разработавшей ее
организации". я_Укомплектованность штатов я.предполагает подбор, набор и зак-
репление специалистов. При этом руководитель обычно озабочен сог-
ласованием двух различных жизненных циклов: жизненного цикла из-
делия и жизненного цикла или продвижения по службе каждого сот-
рудника. Такое согласование часто предполагает, что некоторые це-
ли проекта приносят в жертву долгосрочным целям продвижения по
службе сотрудников, участвующих в разработке. я_Руководимостья. предполагает качественное выполнение следующих
действий: я1мотивации я0- создания и поддержания интереса и стимулов,
побуждающих людей прилагать усилия для успеха проекта; я1организа-
я1ции общения я0- создания и поддержания необходимых сведений о про-
екте и его окружении для участников проекта; я1руководства сотруд-
я1никами я0- руководства сотрудниками - улучшения понимания факторов,
обеспечивающих мотивацию и учет их в решениях руководства. я_Контролируемостья. предполагает сравнение результатов проекти-
рования с установленными целями и планами, исправление отклонений
в разработках. я_Автоматизируемостья. предполагает использование вычислительной
техники для освобождения разработчиков от ручной работы. я_Следование модифицированному золотому правилуя. предполагает
наличие равного отношения к проекту исполнителя и руководителя. я_я2Эффективность процесса разработки АЭИС: управление ресурсами я_Анализируемость эффективности затратя. обеспечение тщательного
анализа затрат и ресурсов для всех возможных подходов к проекти-
рованию при выборе оптимального проекта. я_Планируемость и контролируемостья. предполагает составление и
контроль графиков выполнения проекта, планов координации ресурсов. я_я2Эффективность процесса разработки АЭИС: программотехника я_Осуществимостья. предполагает формулировку предпочтительного
замысла функционирования ИС, установление реализуемости проекта с
учетом всего жизненного цикла и определение его преимущества по
сравнению с другими предложениями. я_Полнота и непротиворечивость требованийя. предполагает разра-
ботку спецификаций функций, интерфейсов и технических характерис-
тик ИС. я_Проектируемость изделия я.предполагает разработку спецификаций
полной аппаратно-программной архитектуры, структур управления и
данных изделия. я_Программируемостья., т.е. возможность разработки полного набора
программных компонентов. я_Комплексируемостья., т.е. возможность получения получения пра-
вильно функционирующей готовой информационной системы из отдель-
ных аппаратных и программных компонентов. я_Внедряемостья., т.е. возможность получения функционирующей в
полном объеме производственной аппаратно-программной системы, за-
пуск ее в производство и налаживание обучения пользователей. я_Сопровождаемостья., т.е. возможность получения функционирующей
в полном объеме модификации аппаратно-программной системы. я_Снимаемость я.предполагает планомерную передачу функций изде-
лия ено преемнику. я_Управляемость конфигурацией я.ИС предполагает, что в любой мо-
мент проектирования можно представить его полную версию или базо-
вые версии, процесс разработки которых происходит следующим обра-
зом: разрабатывается начальная версия изделия; начальная версия
верифицируется, подтверждается, а при необходимости - дорабатыва-
ется; в результате формального анализа устанавливается, находится
ли изделие в состоянии, удовлетворительном для того, чтобы можно
было перейти к идентификации базовой версии, подлежащей формаль-
ному контролю изменений. Базовые версии имеют следующие достоинства: 1) никакие изме-
нения не производятся без согласия заинтересованных сторон; 2)
наложение ограничений на изменения стабилизирует изделие; 3) сот-
рудник, ответственный за управление конфигурацией в любой момент
имеет полную версию изделия. Кроме того, в структуре целей рассматривается подцель - я_Ве-
я_рификация и подтверждениея., которые определяются следующим образом: - верификация - установление соответствия изделия его специ-
фикации (неформально - установление правильности его построения); - подтверждение - установление пригодности или соответствия
его производственному назначению (неформально - установление не-
обходимости его разработки и полезности) 5. Жизненный цикл; эффективность технологии проектирования
автоматизированных экономических информационных систем (АЭИС)
(16.1). Понятие "жизненного цикла", используемое в традиционных из-
делиях промышленности, нашло свое отражение и в производстве АЭИС
и его элементов (аппаратного и программного обеспечения). Несмот-
ря на кажущуюся схожесть описаний жизненного цикла изделий про-
мышленности и АЭИС, имеются глубокие различия в содержании от-
дельных этапов этапов. Так широкий спектр содержательных показа-
телей, которые с различных сторон характеризуют АЭИС, и невысокая
достоверность оценки их значений способствует возрастанию диспер-
сии при попытке описать создаваемые или используемые АЭИС. Жизненный цикл (ЖЦ) АЭИС включает в себя все этапы развития
от возникновения потребности в информационной системе определен-
ного целевого назначения до полного прекращения ее использования
вследствие морального старения или потери необходимости решения
поставленных при создании системы задач. По длительности ЖЦ АЭИС разделяется на два класса: - системы с малой длительностью эксплуатации, предназначен-
ные для получения конкретных результатов вычислений. Они относи-
тельно невелики (до 10 тысяч команд), разрабатываются, как прави-
ло, одним специалистом или небольшой группой, не предназначены
для тиражирования и передачи для последующего использования, пре-
обладают в научных организациях и ВУЗах; Системы с большой длительностью эксплуатации создаются для
регулярной обработки экономической информации. Размеры их колеб-
лются в широких размерах (от 10 до 1000 тыс. команд), они могут
подвергаться модернизации в процессе их длительного сопровожде-
ния, допускается большой объем их тиражирования, они снабжаются
документацией, как промышленные изделия, преобладают в проектных
и отраслевых организациях. Формально ЖЦ АЭИС может быть представлен приведенной ниже
схемой:
я_Появление пот-я. я_Техничес-я. я_АЭИСя. я_Прекращение
я_ребности и по-я. я_кое зада-я. я_эксплуатации
я_становка задачия. я_ние ЪДДДДДДДДДДДї ЪДДДДДДДДДДї ЪДДДДДДДДДДї ДДДДДДґ Системный ГДДДДДДДґ Проекти- ГДДДДДДДґ Эксплуа- ГДДДДД ЪДДДґ анализ і ЪДДДґ рование і ЪДДДґ тация і і АДДДДДДДДДДДЩ і АДДДДДДДДДДЩ і АДДДДВДДДДДЩ і і і ЪДДДДБДДДДДїРезуль- АДДДДДДДДДДДДДДДДДДДБДДДДДДДДДДДДДДДДДДБДДДґ Сопрово- ітат эк- Расширение функций Устранение ошибок і ждение ісплуа- АДДДДДДДДДДЩтации В ходе я_системного анализая. определяют потребность в АЭИС, его
назначение и основные функциональные характеристики, оцениваются
затраты и возможная эффективность применения. я_Проектированиея. включает разработку структуры АЭИС и ее ком-
понент (элементов), программирование модулей и этапов их отладки,
а также испытания и внедрение для регулярной эксплуатации создан-
ной версии АЭИС. я_Эксплуатацияя. заключается в исполнении, функционировании сис-
темы и получении результатов, являющихся целью создания АЭИС, а
также в обеспечении достоверности и надежности выдаваемых данных. я_Сопровождениея. системы состоит в эксплуатационном обслужива-
нии, развитии функциональных возможностей и повышении эксплуата-
ционных характеристик АЭИС, в тиражировании и адаптации ее на
различных типах вычислительной техники. Существует следующая иерархия жизненного цикла АЭИС; - жизненный цикл программы - это процесс разработки и ис-
пользования программы, как приоритетной составляющей системы; - жизненный цикл аппаратного и программного обеспечения -
это процесс создания и применения элементов системы от начала до
конца ее функционирования как единого целого; - жизненный цикл АЭИС - это совокупность процессов с начала
выработки требований ко всей создаваемой системе, и кончая вводом
в действие, текущего обслуживания и сопровождения системы в рабо-
тоспособном состоянии. Проектирование занимает особое место в жизненном цикле ин-
формационной системы. Специалистами установлено, что стоимость
выявления и исправления на более поздних стадиях жизненного цикла
ошибок, допущенных при проектировании и его отдельных фазах, воз-
растает в десятки раз. Поэтому большие усилия направлены на со-
вершенствование специальных языков проектирования и трансляторов,
на развитие методов формализованной отладки, на создание простей-
ших систем автоматизации программирования и проектирования для
отдельных типов ЭВМ, включая персональные, т.е. на наиболее фор-
мализованных этапах технологического процесса создания информаци-
онных систем. Одновременно постоянно развивается и совершенству-
ется теория и практика спецификаций систем, позволяющие формали-
зовать начальные этапы создания АЭИС. Принципиальная схема цикла проектирования системы представ- ЪДДДДДДДДДДДДДДї лена на рисунке слева. іВыявление тре-і Проектирование АЭИС на- іваний пользо-і чинается с определения набо- івателей і ра я_требований пользователяя. и АДДДДДДВДДДДДДДЩ и построения я_функциональной ЪДДДДДДБДДДДДДДї я_спецификациия., вытекающей из іРазработка фу-і требований пользователя. інкциональной і Требования пользователя іспецификации і определяют, что пользователь АДДДДДДВДДДДДДДЩ хочет от системы, и что она ЪДДДДДДБДДДДДДДї должна делать. іПроектированиеі Функциональной специфи- ісистемы і кацией определяют основные АДДДДДДВДДДДДДДЩ функции, выполняемые систе- ЪДДДДДДДБДДДДДДДДї мой для пользователя, после
ЪДДДДДДДДБДДДДДї ЪДДДДДДБДДДДДДДї завершения проектирования.
Проектированиеі іПроектированиеі Она включает описания форма-
аппаратуры і іпрограммы і тов на входе и выходе, а та-
АДДДДДДДДВДДДДДЩ АДДДДДДВДДДДДДДЩ кже внешние условия, управ-
ЪДДДДДДДДБДДДДДї ЪДДДДДДБДДДДДДДї ляющие действиями системы.
Конструирова- і іКонструирова- і Функциональная система
ние аппаратурыі іние программы і и требования пользователя
АДДДДДДДДВДДДДДЩ АДДДДДДВДДДДДДДЩ являются критериями оценки
ЪДДДДДДДДБДДДДДї ЪДДДДДДБДДДДДДДї функциональных характеристик
Комплексирова-і іКомплексирова-і системы после завершения
ние аппаратурыі іние программыі проектирования.
АДДДДДДДДВДДДДДЩ АДДДДДДВДДДДДДДЩ Следующим шагом являет- АДДДДДДДВДДДДДДДДЩ ся я_проектирование я. я_системыя., ЪДДДДДДДБДДДДДДї причем для АЭИС, построенной іКомплексирова-і на базе ПЭВМ, требуется про- іние системы і ектирование как аппаратной АДДДДДДДВДДДДДДЩ части (архитектуры), так и ЪДДДДДДДБДДДДДДї программного обеспечения. іОценка систе-і При этом проектирование імы і аппаратной части может быть АДДДДДДДДДДДДДДЩ выполнено с использованием
стандартной методологии проектирования, а проектирование програм-
много обеспечения (ПО) - с использованием я_языка проектированияя.. Две части системы разрабатываются параллельно, что на приве-
денном рисунке выглядит в виде отдельных ветвей. В настоящее время проблемы проектирования системы сводятся,
главным образом, к сложности ПО. Одним из основных средств сниже-
ния сложности ПО для приемлемого уровня является использование
методологии системного проектирования, включающего, помимо вышеу-
помянутого языка проектирования, использование я_методов нисходяще-
я_го модульного проектированияя.. Выбор наиболее адекватных экономических критериев для обоб-
щенного описания эффективности создания и использования АЭИС за-
висит от их назначения, области применения и других факторов. Во
многих случаях преобладает экономический эффект, который наиболее
просто и обобщенно можно описать суммарным доходом от использова-
ния АЭИС в течение ее жизненного цикла. Этот доход можно предста-
вить как разность между суммарным эффектом и суммарными затратами
(сюда могут быть включены также потери), снижающими этот доход: Э = Э - С При создании АЭИС важнейшей задачей является максимизация
экономической эффективности функционирования. Эффективность технологии проектирования АЭИС достигается за
счет четкой организации труда коллективов специалистов, примене-
ния диалогового режима работы, языков программирования различного
уровня, баз данных и других современных автоматизированных
средств повышения производительности труда проектировщиков и раз-
работчиков. Уровень эффективности зависит от того, при каких затратах на
разработку и эксплуатацию достигаются высокие результаты от при-
менения АЭИС. Эффективность технологии проектирования АЭИС опосредствован-
но влияет на снижение затрат совокупного общественного труда,
направленного на производство промышленной продукции с использо-
вание вычислительной техники. Экономический эффект от применения АЭИС можно выразить дохо-
дом, повышением прибыли или производительности труда, снижением
материало- и энергопотребления и другими экономическими показате- Динамику совершенствования АЭИС наиболее полно характеризует
величина экономической эффективности, отнесенная к совокупным
затратам, при которых она достигается. Этот показатель позволяет
учитывать прирост эффективности на единицу затрат, и при больших
затратах ограничивает качество системы. Глобальная оптимизация эффективности АЭИС на всем жизненном
цикле весьма сложна и в большинстве случаев у разработчиков пре-
валирует стремление оптимизировать этот показатель лишь на неко-
тором интервале времени. 6. Технологические аспекты проектирования автоматизированных
экономических информационных систем (АЭИС) (17.1). Процесс проектирования занимает особое место в жизненном
цикле(ЖЦ) информационных систем (ИС). Установлено, что стоимость
выявления и исправления на более поздних стадиях ЖЦ ошибок, допу-
щенных при проектировании, возрастает в десятки раз. Поэтому уси-
лия направлены на: совершенствование языков и, соответственно,
трансляторов для проектирования и программирования; развитие ме-
тодов формализованной отладки; создание простейших систем автома-
тизации проектирования и программирования для всех типов ЭВМ,
т.е. на наиболее формализованные этапы технологического процесса
создания ИС. Одновременно получает развитие и совершенствование
теория и практика спецификации систем, позволяющая формализовать
начальные этапы создания АЭИС. В свою очередь, это приводит к не-
обходимости индустриализации проектирования, создания технологи-
ческих процессов разработки ИС. Под технологическим процессом понимается совокупность произ-
водственных процессов, методы и средства автоматизации, обеспечи-
вающих разработку и развитие информационных систем заданного типа
и с требуемым качеством в течение всего жизненного цикла. Проектирование информационных систем охватывает комплекс ра-
бот от выработки требований к создаваемой системе до формирования
ее описания. В большинстве моделей АЭИС, основывающихся на кон-
цепции жизненного цикла, проектирование рассматривается как одна
из фаз ее разработки. Формально исходными данными для этой фазы
являются требования, изложенные в спецификации. В процессе этой
фазы принимаются проектные решения, касающиеся способов удовлет-
ворения требований спецификаций. Фаза разработки проекта системы может быть разделена на два
основных этапа: я_архитектурное проектированиея. и я_рабочее проектиро-
я_ваниея.. Первое завершается составлением описания системы в самом
общем виде. Обычно оно содержит сведения об основных компонентах
системы и их взаимосвязях: алгоритмах, которые задействованы в
этих компонентах, и структурах данных. Во втором общее архитек-
турное описание системы детализируется до такого уровня, который
делает возможным работы по ее реализации. я_Современная индустриальная технология проектированияя. АЭИС
включает в себя комплекс мероприятий, руководящих документов и
автоматизированных средств, предназначенных для системного анали-
за, разработки, отладки, документирования, управления работой
специалистов и контроля эксплуатации систем. Значительный эффект
может дать многократное использование хорошо отработанных компо-
нент (модулей) системы в качестве комплектующих изделий. Это поз-
волит существенно сократить дублирующие разработки, внедрить сбо-
рочное программирование и вести накопление на предприятиях и в
стране высококачественного информационного продукта для его мно-
гократного использования. В результате внедрения прогрессивных современных технологий
возможно повышение производительности труда и существенное сокра-
щение сроков создания сложных АЭИС. Важное значение имеют конт-
роль и обеспечение высокого качества систем. Принцип построения модели ЖЦ программы показал наличие ос-
новных видов работ над проектом системы, повторяющихся в отдель-
ной или даже в каждой фазе: анализ требований (учет пользователь-
ских запросов, определение, спецификация, анализ и модификация
функциональных, технических, интерфейсных и верефицировочных тре-
бований); проектирование системы (определение, спецификация, ана-
лиз и модификация аппаратно-программной архитектуры, программы
проекта и базы данных); программирование (детальное проектирова-
ние, кодирование, автономная отладка и комплексирование отдельных
компонентов системы, а также планирование работы системных и
прикладных программистов, приобретение инструментальных техничес-
ких и программных средств, разработка базы данных, документирова-
ние отдельных компонентов и организация программирования на уров-
не компонентов); планирование отладки и испытаний (спецификация
анализ и модификация планов отладки изделия и лабораторных (при-
емных) испытаний; приобретение тестовых драйверов, средств отлад-
ки и тестовых данных); верификация и подтверждение (независимое
выполнение подтверждения исходных требований; используется при
анализе и отладке системы, проведении приемочных испытаний; вклю-
чает также приобретение соответствующих инструментальных
средств); управление проектом (функции руководства проектом: пла-
нирование и контроль проекта, контроль и регулирование договоров
и субдоговоров, связь с пользователями); управление конфигурацией
(идентификация компонентов системы, контроль измерений, анализ
состояния дел, ведение библиотеки поддержания разработки, разра-
ботка и контроль плана приемки конечных компонентов системы);
контроль качества (включает в себя разработку и контроль стандар-
тов и технической проверки аппаратных и программных средств и
программных компонентов системы, а также процессов разработки
всего комплекса); документирование (разработка и корректировка
проектной и технической документации (эскизный, технический и ра-
бочий проекты, руководства пользователей и операторов, инструкции
по сопровождению и т.д.). Из документирования следует особо выде-
лить составление спецификаций - описаний, задающих условия и эф-
фект действия системы, не указывая степень достижения эффекта. Можно дать установочные трактовки следующих фиксированных
состояний АЭИС на основных стадиях его жизненного цикла: потреб-
ность - состояние, в котором свойства АЭИС проявляются посредс-
твом перечня автоматизированных функций и задач в проектируемой
системе, реализация которых возможна только применении вычисли-
тельных средств (из-за габаритных, временных и т.п. характерис-
тик); исходные требования - состояние, в котором свойства АЭИС
проявляются посредством постановок задач, содержащих необходимую
и достаточную совокупность сведений, которые определяют сущность
задач или функций, требования к решению или реализации, исходным
данным и конкретным результатам; алгоритмы функционирования; -
состояние, в котором свойства АЭИС предъявляются посредством
функциональной спецификации, содержащей взаимосвязи всего мно-
жества функций и задач, принципиальные соглашения и решения, об-
щие принципы функционирования, взаимодействие с окружающей сре-
дой. Под окружающей средой АЭИС понимается оконечное оборудова-
ние, а также обслуживающий или управляющий персонал; алгоритм
системы - состояние, в котором свойства АЭИС проявляются посредс-
твом детализированной спецификации, содержащей совокупность пред-
писаний, однозначно определяющих вычислительный процесс выполне-
ния функций или решения задач, и окончательные технические реше-
ния по функционированию, взаимодействию с окружающей средой, сос-
таву отдельных частей (компонент); опытный образец программы сос-
тояние, в котором свойства АЭИС проявляются посредством программы
на носителе данных и программной документацией, используемых в
качестве представителя АЭИС при исследовании, контроле или оценке
в этом состоянии АЭИС способна реализовать возложенные на нее
функции, прошло предварительные испытания, документации присвоена
литера "О"; подлинник системы - состояние, в котором свойства
АЭИС проявляются посредством аппаратно-программного комплекса, а
также технической и программной документации, пригодных для про-
мышленного производства. Таким образом, это такое состояние, ког-
да АЭИС доказало свою способность реализовать возложенные на него
функции и программной документации присвоена литера "О", доказа-
тельством способности АЭИС реализовать возложенные на него функ-
ции являются результаты государственных испытаний и проведенная
доработка системы по результатам этих испытаний; система как из-
делие - состояние, в котором его свойства проявляются посредством
функционирующего в реальных условий комплекса и эксплуатационной
документации, являющихся продуктом промышленного производства,
завершенное изделие представляет собой конечное состояние АЭИС, в
котором оно передается пользователю для эксплуатации. Общая технологическая схема является основой для создания
семейства автоматизированных технологий и технологических линий
производства информационных систем различных классов с нарастаю-
щими возможностями по мощности, производительности, широте и сте-
пени автоматизации работ. Для получения АЭИС высокого качества при допустимых затратах
необходима комплексная разработка технологических процессов с
развитыми средствами инструментальной, методической и организаци-
онной поддержки их проектирования. Эффективность любого технологического процесса проектирова-
ния и создания изделий зависит от: системности его разработки;
единства и взаимосвязанности всех компонент технологии; степени
контроля качества компонент изделия на последовательных этапах
его разработки. Технология разработки АЭИС в современной интерпретации вклю-
чает в себя следующие задачи: - планирование и организация всего технологического процесса
вплоть до серийного изготовления систем, построенных на основе
спроектированных аппаратных и программных средств; - разработка математических моделей, алгоритмов, программ и
других компонент системы на всех стадиях проектирования; - обеспечение программирования алгоритмов, включающего зада-
чи автоматизации процесса программирования, унификации типовых
компонент программ и т.д.; - обеспечение отладки системы с использованием различных ме-
тодов контроля, обнаружения, диагностики ошибок и корректировки
системы; - обеспечение испытаний аппаратных и программных компонент и
всей системы; - автоматизация изготовления документов, обеспечивающих се-
рийное воспроизведение, контроль качества и эксплуатацию системы. Технологический процесс разработки АЭИС частично поддержива-
ется в настоящее время отдельными технологическими средствами
(редакторы, трансляторы и т.п.) или же комплексами технологичес-
ких средств, отнесенных к так называемым системам проектирования
или программирования. Такие средства позволяют создавать АЭИС для
определенных предметных областей их применения с первоначально
определенными жесткими характеристиками, или же АЭИС широкого
класса применения, характеристики которых в каждый конкретный мо-
мент времени соответствуют пользовательским требованиям. Для получения АЭИС высокого качества при допустимых затратах
необходима комплексная разработка технологических процессов с
развитыми средствами методической, технологической, инструмен-
тальной и организационной поддержки. 7. Системотехнические принципы проектирования автоматизиро-
ванных экономических информационных систем (АЭИС); классы систем
- объектов проектирования; декомпозиция как метод проектирования
сложных АЭИС (18.1). Методологией анализа и построения информационных систем,
учитывающих их специфику, является системный подход, а область
науки и техники, изучающая технические проблемы с позиции систем-
ного подхода, называется я_системотехникойя.. Системотехника имеет
важное значение благодаря тому, что ее положения предписывают
проектировщику информационной системы определенный образ действия
и во многом предопределяют направления его мышления. Методология проектирования информационных систем может быть
сформулирована следующим образом: проектирование системы есть
циклический, "итерационный" процесс, проходящий от общего (систе-
мы) к частному (элемент системы) и обратно к общему с постепенным
уточнением и углублением характеристик на каждом цикле итерации.
Наличие взаимосвязей между элементами системы (включая алгоритм)
и их взаимозависимость усложняют процедуру итерации и требуют от
проектировщика равномерной разработки всех подсистем на тех эта-
пах проектирования, когда учитывается взаимозависимость. Из повседневной практики известны примеры систем как естест-
венного происхождения, так и искус-
ственных. Для последних характер- ЪДДДДДДДДДДДДДДДДДДДДДДДДДї
на схема: вход - функция - выход. і ЪДДДДї і Системный подход в данном слу- іВход 1ДДДґ ГДДДВыход 1і
чае учитывает следующие особенности іВход 2ДДДґСис-ГДДДВыход 2і
современных АЭИС: і...... ітемаі ...... і - многофункциональный характер іВход nДДДґ ГДДДВыход nі
экономических задач; і АДДДДЩ і - большое число составных час- і Внешнее окружение і
тей, действия которых в значитель- АДДДДДДДДДДДДДДДДДДДДДДДДДЩ
ной степени взаимообусловлены; - наличие общей цели функционирования, сложным образом свя-
занной с частными целями отдельных подсистем; - взаимодействие большого числа случайных факторов на про-
цессы проектирования, изготовления и эксплуатации; - сложный характер эксплуатации, в ходе которой, возможно,
изменяются условия функционирования; - необходимость учета экономических факторов. Приоритет системного подхода в проектировании обусловлен
тем, что здесь наблюдается перемещение затрат из сферы производс-
тва (тиражирования) в сферу инженерного проектирования и приклад-
ной науки. Современная индустриальная технология проектирования,
с учетом системного подхода, включает комплекс мероприятий, руко-
водящих документов, средств автоматизации, предназначенных для
системного анализа, разработки, отладки, документирования, управ-
ления работой специалистов и контроля эксплуатации АЭИС. Системный подход предполагает рассмотрение и оценку альтер-
нативных вариантов информационной системы и решение задач оптими-
зации по различным критериям эффективности (одним из важнейших
факторов является экономический). Существует связь между особен-
ностями современных АЭИС и системотехническими принципами проек-
тирования, состоящая в: 1. Многофункциональный характер управления и большое число
взаимозависимых составных частей при наличии общей цели функцио-
нирования отражается в принципах декомпозиции, комплексности и
иерархии. 2. Воздействие большого числа случайных факторов отражается
принципом открытости и итерационностью процесса проектирования. 3. Длительный характер эксплуатации приводит к принципу отк-
рытости. Особенности АЭИС, как и любой другой информационной системы,
определяют следующие основные принципы системного подхода. 1. я_Проектирование должно быть комплекснымя.. Существо этого
принципа состоит в максимально полном анализе связей, существую-
щих как в объекте, так и в управляющей системе. Выделяют следую-
щие условия комплексного подхода: анализ АЭИС, всесторонняя оцен-
ка исходных предпосылок и исследование взаимодействия отдельных
элементов системы; максимально полный учет факторов, влияющих на
качество АЭИС и ее эффективность. 2. я_Процесс проектирования должен иметь иерархическую струк-
я_туруя.. Этот принцип определяет последовательность анализа как объ-
екта, так и АЭИС, т.е. вначале устанавливается выход АЭИС как
единого целого; затем она разбивается на подсистемы (при этом
исследуется вклад каждой из них в результатирующий выход) и т.д. 3. я_Основной метод проектирования сложной системы - метод де-
я_композициия.. я_Декомпозицияя. представляет собой процесс разбиения на
составные части с целью исследования этих частей независимо друг
от друга. Довольно широкое использование метода декомпозиции
обусловлено особенностями процесса принятия решения как в ходе
создания, так и в ходе эксплуатации АЭИС, а именно: наличием про-
тиворечия между объемом работы по получению и переработке инфор-
мации и отводимым на эту работу временем. Один из способов устранения противоречия состоит в разбиении
проблемы или задачи, подлежащих решению, ряд подзадач (проводится
декомпозиция задачи), каждая из которых по объему и сложности та-
кова, что может быть решена за приемлемое время и содержит я_коор-
я_динирующие условияя., обеспечивающие объединение решений частных
задач. Сам процесс проектирования может быть при этом разбит на
ряд взаимосвязанных подпроцессов. Координирующие условия выраба-
тываются в результате декомпозиции исходной задачи, которая реша-
ется за меньшее время и при более ограниченном объеме информации.
Таким образом процесс принятия решения сводится к постановке
частных задач и объединение их решений в решение полной задачи. Разбиение процесса на подпроцессы, общей задачи - на частные
задачи, как правило, соответствует представлению проектирования
АЭИС как совокупности частных целей. Для достижения каждой я_част-
я_ной цели я.необходимы исполнители, средства и связи, представляющие
в совокупностия_ автоматизированную информационную подсистемуя.. Та-
ким образом, АЭИС может содержать ряд автоматизированных экономи-
ческих информационных подсистем, но сама при этом не обязательно
является механическим объединением последних. Особый вид представляет собой я_декомпозиция программыя. - раз-
биение готовой программы на множество составных частей (модулей).
Она осуществляется в соответствии с рядом проектных принципов и
критериев, которые должны находить отражение в выделяемых моду-
лях. В результате декомпозиции в общих чертах определяется струк-
тура будущей системы и программы. Процесс разбиения целостной
программы на модули известен еще как я_высокоуровневое архитектур-
я_ное проектированиея.. С декомпозицией программ тесно связано я_мо-
я_дульное программированиея. - т.е. способ программирования, при ко-
тором вся программа разбивается на группу компонентов, называемых
я_модулямия., каждый со своими контролируемыми размерами, четким наз-
начением и хорошо определенным интерфейсом с внешней средой. 4. я_Проектирование системы - итерационный процесся.. Это озна-
чает, что само проектирование имеет циклический характер и приво-
дит к многократному анализу процесса функционирования проектируе-
мой АЭИС. Необходимость применения этого принципа обусловлена не-
достаточным объемом исходных данных, их низкой точностью и досто-
верностью, что является объективным следствием новизны разработ-
ки: чем больше изменений закладывается в разрабатываемую АЭИС по
сравнению с существующей, тем глубже и длительнее идет итерацион-
ный процесс. Нужно подчеркнуть тесную связь этого принципа с
принципом комплексности, их взаимную обусловленность и необходи-
мость комплексного подхода на каждой новой итерации. 5. я_При проектировании следует предусматривать открытость
я_системыя.. Это означает, что данная АЭИС должна хотя быть достаточ-
ной для решения поставленных задач, но при этом должна также
обеспечивать условия ее развития, совершенствования и модерниза-
ции. Это обусловлено высоким темпом современного научно-техничес-
кого прогресса и направлено на продление срока эксплуатации АЭИС. В результате структурного синтеза выбираются состав и пара-
метры комплекса и его элементов, обеспечивающие максимальную эф-
фективность. Исходные данные на этом шаге - ориентировочные тре-
бования к основным характеристикам технических средств. Цель -
разработка структуры АЭИС. В результате ее решения должны быть
даны ответы на следующие вопросы: - сколько и какие устройства с определенным функциональным
назначением должны применяться (как распределить требования к
техническим характеристикам группы функционально однородных уст-
ройств (например, процессоров, оперативных запоминающих уст-
ройств, каналов связи и т.п.) между элементами группы; - как распределить процесс реализации алгоритма во времени и
пространстве между отдельными устройствами с одинаковыми функцио-
нальными назначениями; - как объединить отдельные устройства для решения общих
функциональных задач. Основная часть исходных данных получается из анализа алго-
ритмов решения функциональных задач. Поэтому исследование алго-
ритмов составляет первую и важнейшую проблему структурного синте-
за, цель которого - сформулировать требования к техническим
средствам, обеспечив рациональное распределение функций по управ-
лению между аппаратурой, программой и оператором. Наилучший вари-
ант выбирается по результатам расчета и анализа показателей эф-
фективности; в процессе построения каждого варианта используется
метод итераций в сочетании с декомпозицией и комплексированием. После уточнения перечня задач, решаемых техническими средс-
твами, переходят к определению требований к их основным характе-
ристикам. Основой для этого служат я_временные диаграммы я.решения
задач, устанавливающих допустимые интервалы решения каждой из
них. Эти данные вместе с имеющимися параметрами позволяют рассчи-
тать требования к производительности АЭИС и объему памяти. На этапе структурного синтеза широко применяются простейшие
математические модели, реже физические модели экономических объ-
ектов и макеты. Иногда задачи структурного синтеза требуют приме-
нения элементов я_топологического синтезая., назначение которого -
выбор размещения элементов системы в пространстве. Это, в част-
ности, приходится делать при широком использовании систем переда-
чи данных. Исходные данные я_параметрического синтезая. - структура АЭИС,
распределение функций (задач) между отдельными устройствами и
программными средствами, требования к производительности системы
и объему памяти. Задача - выбор технических решений, удовлетворя-
ющих поставленным требованиям. Методика параметрического синтеза
предполагает широкое применение различных моделей (например, ма-
кеты) с тщательным контролем принципа баланса точностей для оцен-
ки степени адекватности модели и, следовательно, степени доверия
к результатам моделирования. Варианты оцениваются как как по об-
щему критерию эффективности (с обязательным учетом экономических
факторов и надежности), так и по частным показателям. Принимаются меры, обеспечивающие "открытость" системы. Наи-
более эффективным техническим приемом, обеспечивающим это свойс-
тво, является применение унификации, нормализации и стандартиза-
ции. я_Унификацияя. - первая ступень преемственности - уменьшение
многообразия конструкций (модулей) предназначенных для выполнения
одних и тех же или близких по своему характеру функций. Более вы-
сокая степень преемственности - я_нормализацияя.. Требования нормали-
зации сводятся к применению уже разработанных и, как правило,
промышленно освоенных блоков, узлов, комплектов, а также ограни-
чению номенклатуры материалов и составных элементов. я_Стандартиза-
я_цияя. представляет собой ограничение разнообразия, регламентирова-
ние единства качественных показателей, классификации, кодирова-
ния,терминологии, технических требований, методов испытаний и
т.п., возведенные в ранг государственного закона (ГОСТ). Стандар-
ты определяются и устанавливаются, кроме ГОСТа, требованиями меж-
дународных организаций, в работе которых участвует наша страна. Обеспечение открытости или преемственности с помощью унифи-
кации, нормализации и стандартизации дает возможность развивать
систему, модернизировать ее по частям, приводит к повышению на-
дежности, к сокращению затрат на проектирование и сроков созда-
ния. При этом могут возрасти затраты на эксплуатации системы. По-
этому выбор уровня стандартизации осуществляется итеративно, ме-
тодом последовательных приближений. На этапе эскизного проектиро-
вания может быть проработано и предложено несколько возможных ва-
риантов. Поэтому, как правило, не следует стремиться к точному
решению задачи поиска оптимума общего показателя эффективности, а
следует провести как можно более полное и тщательное количествен-
ное и качественное исследование альтернативных вариантов.
8. Принципы структурного проектирования автоматизированных
экономических информационных систем (АЭИС); структурное проекти-
рование программных компонент; восходящее и нисходящее проектиро-
вание АЭИС; общие правила структурного построения (20.2.). Для обеспечения взаимодействия информационных, технических и
программных средств в единой информационной системе (комплексе)
используются многоуровневые иерархические структуры. я_Иерархия я.представляет собой свойство упорядоченного множест-
ва компонент между которыми установлено отношение приоритета.
Компоненты, между которыми отсутствует предпочтительность, обра-
зуют один иерархический уровень. Иерархия предполагает наличие
следующих типов подчиненности компонент: - я1иерархия целей я0системы и ее составляющих, при которых их
зачастую противоречивые частные цели должны способствовать дости-
жению основной цели функционирования всей системы; этот тип явля-
ется наиболее специфичным по существу и методам представления;
разнообразие назначений и и областей применения сложных АЭИС зат-
рудняет разработку общих методов декомпозиции целей и их анализа; - я1иерархия задач я0и поведения групп системы, обеспечивающих
концептуальное единство единство методов и данных, а также воз-
можность последовательного функционального раскрытия системы;
этот тип связан с иерархией целей системы и ее структурного пост-
роения;структурирование функциональных задач и их иерархического
взаимодействия в значительной степени отражается на реализации
иерархической структуры АЭИС в целом и на ее структурной декомпо-
зицией на функциональные группы программ; - я1иерархия структуры я0системы и взаимодействия программ и
данных, отражающих декомпозицию конкретных компонент комплекса и
оформление реализуемых связей между программами и используемыми
данными; этот тип наиболее доступен для анализа и имеет важное
значение при проектировании сложных АЭИС. я_Многоуровневое иерархическое построение сложных систем я.поз-
воляет ограничить и локализовать на каждом из уровней соответс-
твующие ему компоненты. Всем иерархическим системам присущ ряд
свойств, важнейшими из которых являются: вертикальная соподчинен-
ность, заключающаяся в последовательном упорядоченном расположе-
нии взаимодействующих компонент, составляющих данную АЭИС; право
вмешательства и приоритетного воздействия на компоненты любых
уровней со стороны компонент более высоких иерархических уровней;
взаимозависимость действий компонент верхних уровней от реакций
на воздействия и от функционирования компонент нижних уровней,
информация от которых передается верхним уровням. В иерархических структурах АЭИС образуется два потока взаи-
модействий между компонентами разных уровней: - сверху вниз - координирующие и управляющие воздействия
верхних уровней; - снизу вверх - информация о состоянии и реализации предпи-
санных функций компонентами нижних уровней. Взаимодействие предполагает выбор способа координации и и
реализацию координирующих алгоритмов с выработкой соответствующих
воздействий. Координируемые компоненты имеют некоторую автоном-
ность поведения и подготовки локальных решений. Степень автоном-
ности компонент и интенсивность координирующих воздействий уста-
навливается компромиссом при выделении иерархических уровней. Компоненты нижних уровней влияют на вышестоящие непосредс-
твенно, поставляя информацию о своем состоянии и результатах
функционирования, а также косвенно подготавливая возможные реше-
ния для их выбора на более высоких уровнях. Информация о резуль-
татах функционирования верхних уровней может учитываться компонен-
тами нижних уровней для улучшения собственных решений и для кос-
венной координации. я_Функциональная иерархия данных я.отражает "расстояние" между
расчетом переменной и ее использованием или условную длительность
хранения значений переменной. Переменные или массивы, которые
рассчитываются и используются внутри программного модуля, т.е.
являются результатами промежуточных расчетов, называются я1локаль-
я1нымия0. Взаимодействие двух модулей может осуществляться так, что
некоторые переменные используются только этими модулями. Такие
переменные имеют более широкую область применения и должны хра-
ниться все время, пока не будут вызваны взаимодействующие модули;
они называются я1обменнымия0. Ряд переменных и массивов, используемых многими модулями и
группами системы - это я1глобальные я0переменные, характеризуемые на-
иболее широким использованием и соответствующие высшему иерархи-
ческому уровню среди данных. Они объединяются в информационные
модули и в основном определяют сложные связи внутри системы или
группы программ по получению, использованию и преобразованию ин-
формации. Функциональная иерархия в значительной степени определяет
структурное построение массивов данных и их иерархию. В процессе структурного проектирования подготавливаются пра-
вила построения, оформления и постройки программных модулей и ти-
повые структуры массивов данных. Устанавливаются допустимые типы
межмодульной связи и структура АЭИС в целом. На основе оценок
длительности и частости решения отдельных задач выявляются функ-
циональные алгоритмы с наибольшим потреблением производительности
ПЭВМ, формируются дисциплины взаимодействия процессоров и диспет-
черизации вызова программ, а также оценивается реализуемость дан-
ной АЭИС на выбранном классе ПЭВМ. Предварительное распределение
оперативной памяти и памяти команд должно обеспечивать рациональ-
ное использование этих ресурсов для решения частных функциональ-
ных задач. Формально структурное проектирование состоит из следу-
ющих этапов: - определение структуры; - определение структуры модулей; - распределение производительности ПЭВМ; - распределение памяти ПЭВМ; По принципам построения, языку описания, объему и другим ха-
рактеристикам можно выделить следующие я1иерархические уровни я0прог-
раммных компонент: - операторов и операндов программы, соответствующие компо-
нентам текста программы на языке программирования; они являются
минимальными компонентами, из которых строятся модули (разнообра-
зие операторов сравнительно невелико: 50...100 типов, и каждый
оператор реализуется алгоритмом на базе в среднем 1...10 машинных
команд); с повышением уровня языка программирования возрастает
функциональная сложность операторов; - программных модулей, оформляемых как законченные компонен-
ты текста программы; они решают небольшую функциональную задачу
(реализуются 10...100 операторами языками программирования высо-
кого уровня или 100...1000 операторами ассемблера, таким образом
программа модуля имеет 100...1000 машинных команд; каждый модуль
может использовать на входе около десятков типов переменных, но
встречаются программные модули, обрабатывающие несколько десятков
типов операндов, количество типов выходных данных несколько мень-
ше; если для решения небольшой функциональной задачи требуется
100 операторов или более, то целесообразно провести декомпозицию
задачи на несколько более простых, для реализации каждой из кото-
рых модуль реализуется 50...100 операторами); - функциональные группы программ или пакетов прикладных
программ формируются на базе десятков модулей и решают сложные
автономные функциональные задачи (на их реализацию в ПЭВМ исполь-
зуется около десяти тысяч команд, соответственно возрастает коли-
чество используемых типов переменных и разнообразие выходных дан-
ных, которое практически полностью определяется особенностями
функциональной задачи группы программ; при этом значительно быст-
рее растет количество типов переменных, обрабатываемых модулями и
локализующихся в пределах одного или нескольких модулей); - комплекса программ, оформляемого как завершенное ПС опре-
деленного целевого назначения; он создается для решения особенно
сложных задач обработки экономической информации или вычислитель-
ных задач; в комплексы объединяются несколько или десятки групп
программ для решения общей целевой задачи (размеры комплекса
программ исчисляются сотнями модулей, десятками и сотнями тысяч
машинных команд). Иерархическое многоуровневой построение АЭИС существенно об-
легчает организацию их проектирования и эксплуатации, сокращает
длительность и стоимость разработки, дает возможность рационально
распределять усилия разработчиков по решению частных задач в со-
ответствии с их важностью для основного целевого назначения систем
с учетом квалификации каждого специалиста. По количеству компо-
нент на разных уровнях с учетом сложности связей можно оценивать
объем выполненной работы и прогнозировать ее перспективы по сро-
кам и трудоемкости, вследствие чего повышается достоверность
контроля состояния процесса проектирования. Многоуровневый иерархический подход позволяет проектировать
сложные АЭИС по принципу я2сверху вниз я0с позиции назначения и наи-
лучшего решения основной целевой задачи всей системы. Это обеспе-
чивает ее концептуальное единство и возможность рационального
распределения ресурсов проектирования по мере декомпозиции компо-
нент. Хотя разделение на иерархические уровни требует некоторых
затрат, в целом ресурсы используются более эффективно, чем при
отсутствии четкой иерархии за счет построения и упрощения компо-
нент на каждом уровне. Иногда основному проектированию сверху вниз сопутствует раз-
работка компонент я2снизу вверхя0. Разработка начинает с модулей ниж-
него уровня, далее переходят к разработке модулей следующего
уровня иерархии и т.д. Достоинством этого принципа является то,
что при переходе к разработке модулей более высокого уровня иерар-
хии модули нижних уровней можно считать готовыми и подключать их
к модулям верхнего уровня на стадии отладки. Однако на практике
при таком подходе отсутствие целостного взгляда на систему с пози-
ции верхнего уровня, определяющего цели ее создания, не позволяет
в ряде случаев принимать верные решения, что приводит повторной
разработке или значительной корректировке модулей. Влияние пов-
торной разработке сказывается тем отрицательнее, чем выше уровень
иерархии, на котором обнаружена ошибка. Разработка систем по это-
му принципу возможна лишь для сравнительно небольших групп прог-
рамм, ограниченных несколькими модулями, когда разработчики спо-
собны оценивать в любое время структуру системы в целом, а также
структуру и функции отдельных модулей на всех уровнях иерархии. Общие правила взаимодействия компонент АЭИС состоят в следу-
ющем: - должна быть унифицирована структура системы и правил
оформления описания каждого аппаратного, программного и информа-
ционного модуля; - каждый модуль характеризуется функциональной закончен-
ностью, автономностью и независимостью в оформлении от модулей,
которые его используют и которые он вызывает; - применяются стандартные правила организации связей по уп-
равлению и информации с другими модулями; - система разрабатывается в виде совокупности небольших по
количеству операторов (до 100) программных модулей, связанных ие-
рархическим образом, что дает возможность полностью и относитель-
но просто уяснить функцию и правила работы отдельных частей и
системы в целом; - должен отсутствовать эффект последействия очередного ис-
полнения программы на последующие исполнения; - регламентировано использование локальных переменных и ре-
гистров ПЭВМ, на которых реализуется система. Перечисленные правила детализируются: 1. я2Правилами связи модулей по управлениюя0. Передача управле-
ния вызываемому модулю всегда осуществляется через его начало,
т.е. через первый оператор или команду, а выход из вызываемого
модуля всегда происходит через его естественное окончание, т.е.
через последний оператор или команду. Модули низших уровней или
одного уровня иерархии могут вызываться для исполнения только мо-
дулями высших уровней, т.е. модули низших уровней не могут вызы-
вать модули высших уровней, а модули одного уровня - вызывать
друг друга. В любом модуле должна быть предусмотрена возможность подклю-
чения контрольных и отладочных средств; операторы, реализующие
эти средства, обычно сосредотачиваются в конце модуля. 2. я2Правилами связи модулей по информации. я0Информация зон
глобальных переменных доступна для использования любыми модулями,
входящими в ЭИС в соответствии с областью действия зоны глобаль-
ных переменных. Локальные переменные доступны лишь в пределах то-
го модуля, в котором они определены или объявлены. Для взаимодействия вызываемых и вызываемых модулей создаются
зоны обменных переменных, информация из которых доступна лишь мо-
дулям непосредственно связанным по управлению. Информация, находящаяся в регистрах вызывающего модуля при
вызове, должна быть сохранена на период выполнения вызываемого
модуля и восстановлена при возврате управления в вызывающий мо-
дуль. Сохранение регистров может осуществлять как вызывающий, так
и вызываемый модуль, однако принятое соглашение должно соблюдать-
ся при всех вызовах модулей. 3. я2Организации структуры модуляя0. Под структурой понимается: я1Заголовок модуляя0, содержащий его имя, комментарий и совокуп-
ность формальных параметров, если таковые имеются. я1Описание глобальных переменных я0и обменной зоны, характеризу-
ющей переменные, которые могут быть переданы программе в качестве
фактических параметров. я1Тело модуля я0- последовательность операторов программы, обес-
печивающих следующие функции модуля: - сохранение регистров ПЭВМ для последующего восстановления
при возврате управления вызывающему модулю; - переключение по параметру, задающему точку входа в модуль,
если его исполнение может начинаться с некоторого внутреннего
оператора; - выполнение операторов, реализующих функциональную задачу
модуля; - запись переменных в обменную зону вызываемого модуля, если
вызывает другой с передачей ему параметров; - передачу управления на начало вызываемого модуля с запоми-
нанием возврата в вызывающий модуль в точку, следующую за вызо-
вом; - перепись результатов исполнения вызванного модуля из об-
менной зоны в локальную зону рассматриваемого модуля или в гло-
бальную зону; - переключение по параметру, задающего точку возврата в вы-
зывающий модуль, если возврат должен осуществляться к оператору,
непосредственно не не следующему за вызовом; - выполнение операторов, реализующих функциональную задачу
программы; - восстановление регистров ПЭВМ; - возврат в модуль, который вызвал рассматриваемый модуль.
9. Элементарные базовые структуры автоматизированных эконо-
мических информационных систем (АЭИС); структурирование данных
АЭИС; типовая структура АЭИС; основные режимы функционирования
систем (21.1.). Существуют программные конструкции системы,которые при иска-
жении исходных данных могут привести к катастрофическим последс-
твиям. Наиболее известной, трудно контролируемой и потенциально
неустойчивой конструкцией является безусловный переход по содер-
жимому ячейки оперативной памяти (оператор GOTO). Поэтому струк-
тура тела модулей и используемые базовые конструкции должны быть
потенциально устойчивыми к аппаратурным сбоям, искажениям исход-
ных данных и ошибкам в программах. Любую программу можно синтези-
ровать на основе элементарных базовых конструкций трех типов: 1. я2Простая вычислительная последовательностья0 заключается в
последовательном преобразовании или перемещении совокупности всех
исходных переменных. Элементарные конструкции при этом поочередно
следуют друг за другом, причем конец предыдущего оператора замы-
кается на начало последующего. 2. я2Альтернативая0 состоит в проверке выполнения некоторого ус-
ловия и в выборе одного или двух операторов преобразования данных
в зависимости от реализации условия. При разветвлении осуществля-
ется однократный проход по одной из ветвей решения задачи. 3. я2Итерацияя0 представляет собой структуру, в которой при каж-
дом обращении один или несколько операторов повторяется более од-
ного раза. Число итераций задается до входы в цикл, а не опреде-
ляться вычислениями внутри цикла, что исключает неопределенность
функционирования программы. Перечисленные конструкции имеют систематизирующее и дисцип-
линирующее значение. Простота исходных конструкций структурного
программирования предотвращает появление сложных информационных
связей и запутанных передач управления. я_Структурированными счита-
я_ются программы, которые не имеют циклов с несколькими выходами,
я_не имеют переходов внутрь циклов или условных операторов и не
я_имеют выходов из внутренней части циклов или условных операторов.
При повышении структурированности модулей снижается сложность
программ, возрастает их наглядность, что способствует сокращению
числа ошибок. Однако за повышение качества приходится расплачи-
ваться дополнительной памятью и временем их реализации на ЭВМ. В большинстве существующих систем информация запоминается в
я_структурах данныхя., представляющих собой организованные наборы за-
писей данных или информации. Между модульной структурой и струк-
турами данных существует связь, которая может быть проиллюстриро-
вана примером отладки системе на уровне языка проектирования. При
этом могут быть использованы две технологии: - просмотр проектирования, который используется для проверки
корректности проекта; автоматизация этого процесса может быть
осуществлена с помощью я_эмулятора просмотрая.; технология просмотра
достаточно проста, если система построена на модульной основе и
каждый модуль разбит на относительно несложные процедуры; - выверка потока данных, которая проверяет правильность об-
работки информации в системе; для этого используются я_диаграммы
я_потока данныхя., управляющие и контролирующие правильность прохода
данных через систему. Существуют несколько способов организации данных. Простейшая
структура данных, состоящая из нескольких элементов, называется
я_спискомя.. Данные запоминаются в последовательности, соответствую-
щей списку (таким же способом, каким они создаются или генериру-
ются). С целью облегчения поиска информации в иерархической
структуре данных, последние должны быть записаны в я_алфавитномя. или
я_цифровомя. порядке по отношению к некоторой я_ключевойя. информации в
структуре данных. я_Сортировкая., я_поиск я.и прерывание в структурах
данных осуществляется с помощью специальных процедур. Важнейшей компонентой ЭИС являются данные, которые поступают
на обработку, накапливаются, преобразуются, хранятся и выдаются
внешним абонентам. Четкое структурирование данных, выполняемое в
процессе проектирования, способствует уменьшению сложности систе-
мы и снижает вероятность ошибок из-за их неправильного использо-
вания. Всю совокупность данных системы можно разделить: 1. я2Простые переменныея0, представляющие собой минимальную ком-
поненту данных, имеющую имя и описание. Наиболее часто использу-
ются следующие типы переменных: - я1вещественныея0, принимающие числовые действительные положи-
тельные и отрицательные значения в заданных пределах; - я1целыея0, принимающие в заданных интервалах только целые по-
ложительные и отрицательные числовые значения, и, так же как для
вещественных переменных, в их описании указывается масштаб предс-
тавления значений или цена младшего разряда; - я1булевыя0, принимающие только два значения: "да" или "нет"
("истина" или "ложь"); - я1двоичныея0, представляющие собой последовательность битов; в
их описании должна представляться кодировка и смысловое содержа-
ние каждого значения переменной; - я1символьныея0, образующие из последовательности байтовых ко-
дов6 каждый из которых соответствует некоторому символу языка
программирования или описания данных. 2. я2Массивыя0, образующиеся из нескольких простых переменных по
некоторым правилам объединения, упорядочения и имеющие собствен-
ное имя, описание и структуру. Это обеспечивает возможность ис-
пользования массива как единой законченной конструкции. Мощность
массива характеризуется числом различных значений простых пере-
менных, составляющих данный массив. Структура массива и правила
упорядочения переменных определяются компромиссом между объемом
памяти для хранения массива и затратами производительности ЭВМ,
необходимыми для выборочного поиска и обращения к данным в масси-
ве. Простые структуры массивов экономны по затратам производи-
тельности ЭВМ для взаимодействия с данными, однако требуют боль-
шого объема памяти. Для повышения надежности системы целесообраз-
но использовать простейшие и четко упорядоченные структуры масси-
вов; каждой усложнение структуры должно обосновываться экономией
памяти или или улучшением динамических характеристик использова-
ния переменных. Наиболее типичными структурами массивов являются: - я1стекя0, для которого единственными операциями являются упо-
рядоченная запись переменной в конец массива и чтение последней
записанной переменной; - я1очередья0, запись в которую новых значений переменных произ-
водится в конец массива, а выбор используемой переменной - из на-
чала массива; - я1реверсивная очередья0, допускающая запись и чтение перемен-
ных для обоих концов массива с некоторыми дополнительными прави-
лами выбора операций; - я1цепочкая0, устанавливающая порядок следования простых пере-
менных (или частных массивов) путем указания в составе каждой пе-
ременной адреса связи к следующей величине того типа и фиксирова-
нием в заголовке списка (специальная ячейка памяти) адреса прос-
той переменной в списке; - я1деревоя0, характеризующееся несколькими адресами связи у
каждой простой переменной (или частного массива), что позволяет
их объединять в разветвленную структуру и изменять направление
поиска в зависимости от результатов проверки некоторого условия. я2Программы обмена с внешними абонентамия0 включают: - я1программы приема сообщений я0от систем передачи данных в АЭИС
определяют буферную зону памяти и место для хранения поступившего
сообщения, а также осуществляют его ввод в буферную зону в соот-
ветствии с заданной дисциплиной; - я1программы выдачи сообщений я0включаются при выполнении двух
условий: готовности канала к передаче сообщения и наличия подго-
товленного к выдаче сообщения соответствующего типа (под типом
сообщения подразумевается номер абонента, которому предназначено
сообщения). Включение этих программ обычно осуществляется аппаратно по
инициативе внешних устройств; управление производится я2диспетчером
я2прерыванийя0, который управляет также программой анализа сбоевя1 я0и,
возможноя1,я0 другими программами. я2Программы организации вычислительного процессая0 включают: - я1программы начального пуска я0осуществляют автоматическое
формирование, контроль и корректировку исходной управляющей ин-
формации в соответствии с заданным режимом функционирования сис-
темы или при его изменении; эта программа обеспечивает сокращение
времени на перевод системы из исходного состояния в заданный ре-
жим работы; в ней могут предусматриваться один или несколько ре-
жимов сокращенного контроля и подготовки исходных данных; - я1программы тактировки периодических вычислений я0(таймер)
осуществляет контроль счетчиков реального времени и запись заявок
на включение периодических программ в соответствии с заданными
для них темпом, дисциплиной, типом программы и ее положением в
шкале приоритетов; включается после поступления сигнала прерыва-
ния от определенного разряда счетчика времени и записи заявки в
шкалу приоритетов центрального диспетчера на включение программы; - я1центральный диспетчер я0управляет включением групп программ,
решающих крупные функциональные или вспомогательные задачи; он
включается после завершения каждой вызываемой им группы программ,
а при отсутствии заявок и сообщений - после завершения анализа
всей шкалы приоритетов; - я1местные диспетчеры я0управляют последовательностью подключе-
ния модулей в процессе решения задачи приоритетной группой прог-
рамм, заданной центральным диспетчером; они включаются централь-
ным диспетчером или функциональными программами после их заверше-
ния; в местных диспетчерских программах реализуются фиксированные
последовательности вызова программных модулей, состав и очеред-
ность которых управляется небольшим количеством условий. - я1программы взаимодействия комплексированных ЭВС или процес-
я1соров я0в составе АЭИС обеспечивают межмашинный обмен информацией и
распределение функциональных задач по процессорам для обеспечения
пропускной способности системы или с целью повышения надежности
решения функциональных задач; - я1программы взаимодействия с внешними накопителями я0позволяют
существенно увеличивать объем памяти, доступной для хранения
программ и информации; для этого они распределяют память внешних
накопителей между различными группами информационных массивов и
программ, осуществляют вызов программ из внешней памяти в опера-
тивную и выбирают массивы, подлежащие замещению. я2Программы контроля и обеспечения надежности я0осуществляют ре-
жимы контроля и восстановления системы в процессе рабочего функ-
ционирования АЭИС. В состав этой группы входят: - я1программа анализа сбоев я0осуществляет регистрацию и накоп-
ление данных о всех выявленных искажениях вычислительного процес-
са и информации, вырабатывает решения по ликвидации последствий
или уменьшения ущерба от выявленного искажения путем включения
соответствующих программ или переключений в аппаратуре; - я1программа анализа загрузки я0ведет учет холостого времени
работы центрального диспетчера, подсчитывает суммарное время ра-
боты по основным программам и программам обмена, сопоставляет ре-
альную загрузку с допустимыми пороговыми уровнями и подготавлива-
ет решения на перестройку структуры системы при переходе значений
загрузки через пороговые значения; - я1программный диагностический тест я0контролирует основные уст-
ройства системы без изменения информации, накопленной в оператив-
ной памяти при решении функциональных задач; - я1контрольная задача я0имитирует решение основных функциональ-
ных задач по подготовленным и зафиксированным сообщениям с точным
сравнением результатов с известным эталоном; - я1программа функционального контроля я0включается при: * приеме сообщений функционального контроля внешних абонен-
тов и периодически для формирования сообщений, обеспечивающих
функциональный контроль аппаратуры внешних абонентов; * выявлении систематических искажений в поступающей информа-
ции для определения их источника; - я1программа контрольной задачи я0обеспечивает запись имитируе-
мых сообщений в память входных сообщений и анализ контрольных со-
общений, подготовленных к выдаче, сравнение результатов обработки
имитированных сообщений с эталонами и исключение их из передавае-
мых внешними абонентами; - я1программа контроля обмена я0включается периодически и обес-
печивает сравнение с эталонами контрольных сообщений, принятых от
внешних абонентов, формирование и подготовку к выдаче контрольных
сообщений для внешних абонентов,а также обобщение и индикацию ре-
зультатов контроля обмена за некоторый интервал времени. я2Программы решения функциональных задач я0(специальное прог-
раммное обеспечение) представлены программными модулями, содержа-
ние, назначение и логические связи которых полностью определяются
типом и задачами системы. Включение функциональных групп программ
осуществляется двумя методами: через местный диспетчер; непос-
редственной передачей управления между программами. В соответствии с функциональным назначением оперативная па-
мять делится на зоны: я2Программ организации вычислительного процессая0, которая в
свою очередь содержит: зону исходных данных текущего режима рабо-
ты, формируемых и используемых программой начального пуска; таб-
лицу приоритетов, содержащую список адресов начальных команд
программ, включаемых центральным диспетчером; шкалу приоритетов,
куда записываются заявки на включение определенных программ и на-
чало списка адресов сообщений, подлежащих обработке по данному
приоритету; таблицу периодических программ, в которой хранятся и
координируются темп и время последнего включения периодических
программ; таблицу выдачи, содержащую список адресов сообщений,
подлежащих выдаче определенным абонентам. я2Входной информациия0, содержащие буферные накопители сообщений
от внешних абонентов. я2Выдаваемой информации я0- подразделяются на части обычно по
номерам абонентов или по длительности передачи одного сообщения,
т.е. в соответствии с делением абонентов на относительно скорост-
ные и медленно действующие. я2Результатов обработки информации я0определяются продолжитель-
ностью хранения и темпом изменения информации в этих зонах. В
свою очередь, делится на: память локальных переменных текущих
расчетов - характеризуется быстрой сменой информации в памяти
(причем любой ячейкой может пользоваться любой программный модуль
или группа программ одного приоритетного уровня) и наличием об-
менных зон для хранения информации; зону хранения глобальных пе-
ременных - результатов процесса управления; состояние этой зоны
определяет устойчивость и непрерывность процесса управления или
обработки информации. я2Контроля я0- содержат результаты функционального контроля сис-
темы. Обеспечивает накопление и анализ информации о состоянии
внешних устройств системы, изменение темпа контроля отдельных ус-
тройств при нарушении их нормальной работы, анализ отказов и вы-
работку рекомендаций на переключение устройств системы. я2Хранения программ я0- используются с внешними накопителями для
хранения программ и констант (магнитные диски, ленты, барабаны).
требует защиты и контроля информации, т.к. даже малые искажения в
программах могут резко изменить характеристики АЭИС. В я2режиме начального пуска я0подготавливаются необходимые ис-
ходные данные для последующего функционирования АЭИС в заданных
режимах. В процессе рабочего функционирования АЭИС режим пуска
включается только при появлении отказов. я2Режим тестового контроля и поиска неисправностей я0разделяется
на два подрежима контроля: - с помощью специальных диагностических тестов; - с помощью контрольных задач, являющихся частью всей систе-
мы, постоянно функционирующей в рабочем режиме. я2Режим функционального контроля я0управляющей системы в значи-
тельной степени связан с режимом начального пуска. Он должен
обеспечивать проверку безопасности включения рабочих режимов, вы-
явление ограничений на функционирование, связанных с состоянием
внешних объектов, и выдачу сводных данных, необходимых для приня-
тия решения о включении управляющей системы и допустимых режимах
ее функционирования. я2Рабочий режимя0, в зависимости от загрузки системы основными
функциональными задачами, включает три подрежима: - я1отсутствия внешних сообщений и ожидания информациия0: систе-
ма включена полностью в управляющий контур и может взаимодейство-
вать с реальными объектами, однако своих основных функциональных
задач не выполняет; она находится в состоянии дежурства или ожи-
дания; рабочий режим сводится к готовности принять и обработать
сообщения и к интенсивному контролю системы и внешних абонентов; - я1рабочего функционирования АЭИС при малой и средней загруз-
я1ке я0системы: включается основная масса программ решения функцио-
нальных задач и устанавливается нормальный темп включения перио-
дических программ; - я1предельной загрузки я0 я1и перегрузки системыя0: рабочий режим
перестраивается для обеспечения решения основных функциональных
задач с допустимыми задержками и потерями входной и выходной ин-
формации. Проектированием программного обеспечения завершается второй
уровень документации. Помимо уже известных программных специфика-
ций, он включает в себя: иерархический список имен подсистем, мо-
дулей и процедур, а также всех структур и параметров; дерево вы-
зова процедур; определение структур данных, используемых в систе-
ме; описание каждой процедуры на языке программирования; дополни-
тельную информацию, необходимую для понимания системы на уровне
проектирования; эта информация может может быть размещена или в
подзаголовке модуля или процедуры, либо в отдельных документах. 10. Проектирование аппаратных средств автоматизированных
экономических информационных систем (АЭИС); модульная структура
аппаратных средств; вопросы экономики при выборе соотношения меж-
ду аппаратными и программными средствами (22.1.). К аппаратным средствам вычислительных (информационных) сис-
тем относятся средства: переработки и отображения информации, уп-
равления и передачи данных. Выбор типов элементов, их количества
и их взаимосвязи в каждой группе во многом определяет эффектив-
ность АЭИС в целом. Решение задачи выбора зависит от заданных ис-
ходных требований и связано с решением задачи разработки прог-
раммного обеспечения, поскольку о определенные функции могут вы-
полняться как аппаратными, так и программными способами. Типы ап-
паратных средств не могут выбираться изолированно друг от друга,
т.к. они должны быть совместимыми по входной и выходной информа-
ции и по физическим параметрам входных и выходных сигналов. Информационная совместимость предполагает единые способы ко-
дирования информации и форматы данных на входных и выходных соп-
рягаемых между собой устройств. Аппаратная совместимость заключа-
ется в овзможности непосредственной электрической связи выходов и
входов отдельных устройств. Наличие информационной и аппаратной
совместимости упрощает построение системы и обеспечивает возмож-
ность ее развития и совершенствования. Основными функциями средств переработки информации (СПИ) в
составе АЭИС являются: прием информации от средств управления, а
также от вншних источников сообщений нпосредственно или через
средства передачи данных; выполнение арифметических и логических
операций в ходе реализации алгормитма управления объектом; урав-
ление процессами обмена с системами обработки информации (СОИ),
системами управления и внешними запоминающими устройствами (ВЗУ);
обмен информации с ВЗУ, выдача информации на СОИ или внешним пот-
ребителям непосредственно через средства передачи данных. В зави-
симости от исходных требований (в основном - от ограничений на
допустимое время реализации алгоритма, время обмена данными и от
заданной надежности и достоверности информации) структура СПИ мо-
жет быть различной. В настоящее время в АЭИС используются: одноп-
роцессорные (П)ЭВМ, многопроцессорные информационно-вычислитель-
ные комплексы, многомашинные вычислительные системы. Большинство проектных решений для аппаратных средств связано
с обеспечением интерфейса между компьютером и его внешней средой.
Теоретически персональная ЭВМ может быть приобретена не только в
укомплектованном виде, но и в виде набора микросхемных модулей на
отдельных кристаллах. Состав информационной системы может изменяться в широких
пределах. Базовый набор компонентов составляют: системный блок,
содержащий основную аппаратную часть - микропроцессоры, контрол-
леры ввода-вывода, интерфейсы, постоянное запоминающее устройство
(ПЗУ), оперативное запоминающее устройство (ОЗУ), сетевые адапте-
ры, обеспечивающие физическое подключение данной ПЭВМ к другим
через сетевые каналы связи, а также другие электронные схемы;
внешние запоминающие устройства; дисплей, служащий для отображе-
ния текстовой или графической информации в черно-белом или цвет-
ном виде; клавиатура, предназначенная для ввода в информационную
систему управляющих команд и данных; печатающее устройство (прин-
тер), обеспчивающее получение твердых (печатных) копий экрана ( в
т.ч. графических и цветных). я_Однопроцессорные (П)ЭВМ; общие принципы построения схем од-
я_нопроцессорной системыя.. Обработка данных производится арифмети-
ко-логическим устройством (АЛУ) под управлением центрального уст-
ройства управления (ЦУУ). ЦУУ вырабатывает необходимые управляю-
щие сигналы для выборки очередной команды из памяти, дешифрации
кодов команды, формирование адресов операндов, выборки операндов
из памяти, передачи их в АЛУ, выполнения в АЛУ операции, предус-
мотренной кодом команды, передачи полученного в АЛУ результата
операции в память, инициирования работы устройства обмена и орга-
низации реакции процессора на запросы прерывания. Основные характеристики процессора, учитываемые при проекти-
ровании системы: быстродействие, состав системы команд, точность
вычислений (количество разрядов машинного слова) и надежность. Для большинства (П)ЭВМ структура памяти может быть представ-
лена как двухуровневая система: внутренняя память (верхний уро-
вень) и внешняя память (нижний уровень). Все ЗУ, входящие в состав внутренней памяти, предназначены
для записи, хранния и выдачи команд и оперативной информации, не-
посредственно участвующей в данный момент времени в процессе вы-
числений. Внешняя память предназначена для более длительного хра-
нения информации. Эти ЗУ, как правило, не имеют непосредственной
связи с процессором. Основной удельный вес среди устройств векш-
ней памяти приходится на ЗУ, использующие движущий магнитный но-
ситель: диски или ленты. К основным параметрам, характеризующим
внешнюю память, относят: емкость, скорость обмена инормацией,
среднее время доступа к информации по заданному адресу. я_Многопроцессорные информационно-вычислительные комплексы
обусловлены развитием параллелизма в работе информационно-вычис-
лительных систем, их отличительной особенностью которых являются: - наличие двух или более процессоров с примрно равными воз-
можностями или специализированных процессоров; - возможность доступа всех процессоров к общей памяти, к ка-
налам устройства ввода-вывода и переферийным устройствам; - наличие единой операционной системы, осуществляющей общее
управление аппаратными и программными средствами (П)ЭВМ; - возможность тесного взаимодействия элементов аппаратного и
программного обеспечения (перераспределения программ между про-
цессорами, обмен данными, прерывание). В зависимости от структуры связи между всеми устройствами
различают многопроцессорные (П)ЭВМ: с общей разделенной во време-
ни шиной; с перекрестной коммутацией; матричные (векторные); с
конвейерной обработкой данных. я_Схема многопроцессорной системы с общей разделенной во вре-
я_мени шинойя. представляет собой простейшую среди многопроцессорных
схему и реализуется с минимальными затратами. Все устройства под-
соединены параллельно к одной двунапрвленной или двум однонаправ-
ленным слева) шинам. Каждый массив информации, переданный на ши-
ну, должен содержать адрес устройства, куда должны быть направле-
ны данные, подлежащие передаче. я_Схема многопроцессорной системы с перекрестной коммутацией
позволяет подсоединять любой блок памяти к любому процессору или
к любому устройству обмена, а через него - к любому переферийному
устройству. Между любыми двумя устройствами на все время передачи
информации устанавливается физический контакт, причем одновремен-
но можно установить несколько путей передачи данных. Это позволя-
ет уменьшить задержки при обмене по сравнению со структурой с об-
щей шиной. В то же время увеличивается объем аппаратуры коммута-
ции. Разновидность этого типа структур - многомашинные многовхо-
довые структуры - также обеспечивают несколько путей одновремен-
ной передачи информации, однако в них каждый блок памяти должен
иметь несколько входов. Система с я_матричной структуройя. содержит несколько одинаковых
сравнительно простых процессоров,соединенных друг с другом так,
что образуется матрица, в узлах которой размещаются процессоры.
Все они выполняют одновременно одну и ту же команду (допускается
пропуск выполнения команды в отдельных процессорах), но над раз-
ными операндами, доставляемыми процессорами из памяти несколькими
потоками данных. По этой причине такие структуры называют струк-
турами типа ОКМД (одинарный поток команд и множественный поток
данных). Система с я_конвейерной обработкойя. содержит цепочку последова-
тельно соединенных процессоров, так что информация на выходе од-
ного процессора является входной информацией для другого процес-
сора. На вход такого "процессорного конвейера" одинарный поток
доставляет операнды из памяти. Каждый процессор обрабатывает со-
ответствующую часть задачи и ее решение развертывается последова-
тельно в конвейерной цепочке. Это обеспечивается подведением к
каждому процессору своего потока команд. Такие структуры называ-
ются системами типа МКОД (множественный поток команд и одинарный
поток данных). я_Многомашинные вычислительные системыя., в отличие от многопро-
цессорных, состоят из нескольких (П)ЭВМ, каждая из которых имеет
свою внутреннюю память и работает под управлением своей операци-
онной системы, и средства обмена информацией между машинами.
Построение многомашинных СПИ из серийных (П)ЭВМ со стандартным
программным обеспечением проще, чем построение многопроцессорных
систем с общим полем памяти и специальной операционной системой. По степени связи между собой выделяют: несвязанные комплек-
сы: нет непосредственного физического соединения между (П)ЭВМ;
объединение осуществляется путем переноса машинного носителя с
одной (П)ЭВМ на другую или переключения внешних запоминающих уст-
ройств; связанные комплексы:(П)ЭВМ электрически соединены между
собой или совместно используют общие аппаратные средства. В любом случае обмен информацией идет через определенную зо-
ну памяти, доступную всем машинам. Эту общую память, используемую
для обмена, называют я_я1памятью обменая.я0. В рассмотренной структуре все машины равноправны (имеется
однородность связей по управлению). Такой вычислительный комплекс
имеет децентрализованную структуру со связанными подсистемами. Затраты на обмен информацией между машинами и конфликты при
обращении машин к памяти обмена приводят к тому, что в процессе
решения взаимосвязанных задач производительность многомашинных
СПИ оказывается меньше суммарной производительности входящих в
состав СПИ машин. В многомашинных СПИ время функционирования каж-
дой машины используется на: исполнение функциональных программ
управления и обработки информации; организацию межмашинного обме-
на; обмен информацией между блоками памяти обмена взаимодействую-
щих машин; ожидание при обращении в собственную память обмена
вследствие обращения к ней в это время другой машины или при об-
ращении к памяти обмена соседней машины, занятой обменом с другой
машиной или взаимодействием с собственной памятью обмена. Другим распространенным принципом организации СПИ в виде
многомашинных комплексов является централизованный. В этом случае
управляющая информация, организующая совместную работу всех ма-
шин, поступает из центральной машины-диспетчера. К основным функ-
циям машины-диспетчера относятся: разбиение программы исходной
задачи на независимые участки; оптимизация распределения этих
участков по машинам; организация обмена информацией между машина-
ми; управление работой всех машин; организация вывода результата;
контроль правильности работы машин и перераспределение загрузки
при отказе одной из машин. Возможны два режима работы машины-дис-
петчера: синхронный и асинхронный. При синхронном режиме этап об-
мена не совмещается во времени с этапом решения и идет после то-
го, как все машины информационно-вычислительной системы закончили
работы над предшествующими частями программы. я_Микропроцессоромя. (МП) называется программно-управляемое уст-
ройство для обработки цифровой информации, реализованное в виде
одной или нескольких больших итегральных схем (БИС). МП делятся
на несколько класоов в зависимости от особенностей их структуры и
основных параметров. В зависимости от способа программирования
различают МП, выполняющие определенный набор команд, и МП, выпл-
няющие набор микрокоманд. Важная характеристика МП - разрядность обрабатываемых с его
помощью данных. По способу обработки многоразрядных кодов разли-
чают МП с фиксированной и с наращиваемой разрядностью. Фиксиро-
ванную разрядность (обычно 8 или 16) имеют МП первого типа, вы-
полняющие фиксированный набор команд. Операнды большей разряднос-
ти обрабатываются с помощью такого по частям, обычно байтами (по
8 разрядов). Обработка байтов выполняется последовательно, поэто-
му быстродействие при работе с многоразрядными кодами существенно
уменьшается. МП с наращиваемой разрядностью обычно содержат 2 или
4 разряда. Для обработки многоразрядных кодов параллельно включа-
ются несколько МП, между которыми передаются необходимые сигналы
переноса, возникающие при выполнении арифметических операций,
сдвигов и т.п. В МП с наращиваемой разрядностью обычно использу-
ется микропрограммное управление. я_Иерархическая многоуровневая памятья.. В современных информа-
ционно-вычислительных системах используются запоминающие устройс-
тва разных типов, различающиеся физическими принципами запомина-
ния, техническими и экономическими характеристиками. Использование многоуровневой памяти позволяет снизить сум-
марную стоимость хранения больших объемов информации при некото-
ром допустимом снижении производительности системы. Это достига-
ется использованием самых быстродействующих (но и дорогих) ЗУ от-
носительно небольшого объема для непосредственного взаимодействия
с процессором (внутренняя память - сверхоперативные ЗУ, главная
оперативная память, память команд и констант). Следующее устройс-
тво памяти с меьшим быстродействием и большим объемом непосредс-
твенно не связано с процессором и снабжает данными память высшего
уровня (внутренняя память - большая оперативная память). Поскольку на долю памяти приходится большая часто затрат
объема и стоимости аппаратуры информационно-вычислительной систе-
мы, вопросы рационального построения иерархической структуры за-
поминающих устройств приобретают первостепенное значение. Основные задачи рационального выбора системы запоминающих
устройств решаются при выборе параметров и структуры средств пе-
реработки информации. Для этого должны быть сделаны (исходя из
системных соображений) ориентировочные оценки общей емкости памя-
ти. В информационно-вычислительной смистеме память используется
для хранения следующей информации: программ решения функциональ-
ных задач и управления вычислительным процессом, данных от внеш-
них источников, результатов решения функциональных задач, проме-
жуточных результатов и констант. Оценки всех объемов на начальных этапах проектирования не
учитывают возможностей совмещения отдельных массивов или их час-
тичного перекрытия, требований мультипрограммной работы, требова-
ний к надежности системы и к достоверности информации. Поэтому
все они подлежат систематическому уточнению на всех этапах проек-
тирования. я_Средства отображения и управленияя. обеспечивают связи опера-
тора с техническими средствами АЭИС. Функциональное назначение
этих устройств различно. я_Средства отбраженияя. информации (СОИ) предназначены для пред-
ставления оператору информации о состоянии системы и внешней сре-
ды в удобной для восприятия (в подавляющем большинстве случаев -
визуальной) форме. Они подразделяются на: я_Средства управленияя. (СУ) предназначены для ввода в систему
управляющего воздействия оператора. Они представляют собой одну
из разновидностей устройств ввода информации. Это - устройства
ручного ввода (в отличие от устройств автоматического ввода, к
которым относятся устройства ввода с машинных носителей, графи-
ческие устройства ввода и читающие автоматы). Преимущественное
применение устройств ручного ввода объясняется постоянным соста-
вом функциональных задач и высоким постоянством констант, а также
стремлением упроостить действия, выполняемые оператором. я_Средства передачи информациия.. Для связи устройств АЭИС, уда-
ленных друг от друга, обычно используется специальная аппаратура
передачи данных (АПД). В состав АПД входят устройства: -я2 я_устройство защиты от ошибокя.я0 - обеспечивает кодирование
отправляемой информации с помощью помехоутойчивых кодов и декоди-
рование принимаемой информации в обычный двоичный код. -я2 я_демодуляции и модуляции (модем)я.я0 - в качестве передатчика
преобразует закодированное сообщение в модулированный сигнал, со-
ответствующий физической среде, в которой он проходит от передат-
чика к приемнику (такой средой могут быть провода в проводных и
кабельных линиях, воздушная среда в радиолиниях, волноводы и све-
товоды в перспективных системах). -я2 я_вызовая.я0 - служит для организации связи. Совокупность устройств и среда, обеспечивающая независимую
передачу сигналов от передатчика к приемнику называется я_я1каналом
я_я1связия.я0. Для снижения стоимости систем передачи информации и улуч-
шения массогабаритных Для снижения стоимости систем передачи информации и улучше-
ния массогабаритных показателей целесообразно использовать одни и
те же элементы среды (линии связи) для передачи сообщений между
несколькими передатчиками и приемниками. Такая сявзь называется
я_я1многоканальной связьюя.я0, а аппаратура, позволяющая на одной линии
связзи образовать два или более каналов, называется многоканаль-
ной аппаратурой или я_я1аппаратурой уплотненияя.я0. В современных системах многоканальной связи чаще всего в ка-
честве переносчиков используются либо синусоидальные колебания,
либо последовательности импульсов. В каждом конкретном случае ис-
пользуются наиболее подходящие способы разделения канальных сиг-
налов. Принцип многоканальной связи реализуется на частотном и
временном разделении каналов.
следующие вопросы 11. Проектирование программного обеспечения автоматизирован-
ных экономических информационных систем (АЭИС); система языков
проектирования программ; комплексирование программ; средства ав-
томатизации разработки программ (23.1.). Эффективность технологий проектирования во многом определя-
ется языками проектирования, обеспечивающими общение специалис-
тов-разработчиков со средствами автоматизации их труда. Унифика-
ция языков проектирования позволяет обмениваться программными
средствами или их компонентами, сокращает затраты на освоение
языков и на технологические средства автоматизации их использова-
ния, способствует переносимости и повышению качества ПС. В связи с разноплановостью задач, решаемых на различных тех-
нологических этапах разработки, целесообразна взаимосвязанная
система языков, включающая (в порядке упрощения проблемной ориен-
тировки и усложнения машинной ориентировки): Язык управления задачами Язык подготовки технологических средств Язык спецификаций требований Алгоритмический язык программирования Макроязык программирования Автокоды (ассемблеры) Языки отладки: в статике; в реальном времени Главными требованиями, предъявляемыми к системе языков про-
ектирования, являются: технологичность разработки ПС методом мо-
дального нисходящего проектирования; получение надежного ПС; мо-
бильность ПС, т.е.переносимость программных компонент как для
различных объектных, так и технологических ЭВМ; сопровождаемость
ПС в течение всего жизненного цикла. Требования включают в себя также простоту написания прог-
рамм, познаваемость их, удобство общения пользователя с техноло-
гической ЭВМ во всех режимах. Рационально разграничивать исполь-
зование средств языка на различных этапах проектирования ПС между
различными группами разработчиков; системными программистами,
настройщиками кросс-систем на конкретные ЭВМ, разработчиками
функциональных программ и специалистами по комплексированию прог-
раммных компонент. Характеристика языков проектирования: я1Языком управления заданиямия0 обеспечиваются все этапы техно-
логии. Технологические системы оснащаются монитором с языком уп-
равления заданиями, в т.ч. управления базой данных в различных
режимах. Эти достигаются переносимость технологической системы и
унификация управления ее работой. Язык управления заданиями
представляет собой набор директив, имеющих фиксированный синтак-
сис. Для таких действий, как управление БД и диалог, набор дирек-
тив стандартизирован; для других функциональных подсистем набор
директив определяется их функциями. Элементами являются диагнос-
тические сообщения об обнаруженных ошибках. я1Язык подготовки технологических средств я0доступен настройщи-
кам пс на среду функционирования. В него включается раздел,
представляющий собой пакет описания общих типов данных, их атри-
бутов и машинно-зависимых процедур. Язык определяет правила пос-
ледовательности команд при реализации операторов алгоритмического
языка или макроязыка. Для алгоритмического языка это могут быть
семантические проблемно-ориентированные языки, в которых исполь-
зуются некоторые конструкции алгоритмического базового языка,
частности настраиваемые элементы, процедуры и операторы ветвле-
ния. Язык задания форм выходных документов и машинных носителей
определяет расположение информации на текстовых документах (лис-
тинг программы, распределение памяти и др.) и машинных носителях. я1Язык спецификации требований я0предназначен для оформления ре-
шений, принятых при структурном проектировании ПС. На нем специ-
фицируются весь комплекс программ, группы программ и частные
программы (процедуры), а также пакеты данных. В спецификациях от-
ражаются основные характеристики программ, связь их между собой
по управлению и информации, а также схема функционирования. я1Языки программирования я0поддерживают этап разработки прог-
рамм. К программам ЭВМ предъявляются высокие требования по эффек-
тивному использованию вычислительных ресурсов. К этой группе от-
носятся: алгоритмические языки,макроязыки и автокоды. я2Алгоритмические языки я0при конкретном применении являются
подмножеством базового языка. Основными свойствами алгоритмичес-
ких языков являются: типизация языка, возможность определения но-
вых типов данных, в т.ч. индексируемых, комбинированных и ссылоч-
ных типов с указанием ограничений на область значений, возмож-
ность семантического контроля применения данных различных типов;
структурированность программных компонент и данных, строгое опре-
деление структурных операторов; наличие пакетов, содержащих опи-
сания глобальных данных, типов и процедур; наличие задач, обеспе-
чивающих описание параллельного исполнения программ; обеспечение
раздельной компиляции частных программ и пакетов данных. наличие
настраиваемых элементов языка (процедур, операций) привязки к
конкретной ЭВМ и т.д. я2Макроязыки я0(машинно-зависимые алгоритмические языки) исполь-
зуются для записи программ с применением операторов, наиболее
адекватно отражающих действия групп команд конкретной ЭВМ (ариф-
метики с присваиванием, сравнения с переходом, организации цикла
и переключателя и др.). В состав макроязыка входят операторы, со-
ответствующие структурным операторам алгоритмического языка. я2Автокоды я0(ассемблеры), в которые включаются макросредства
(системные и структурные макрокоманды), обеспечивающие интерфейс
между программами, записанными на языках более высоких уровней, а
также структуризацию программ. я1Языки, используемые на этапе отладки программ я0обеспечивают
проведение контроля результатов работы программы по различным ис-
ходным данным. Этот тип включает: язык отладки в статике, который
дает возможность задавать указания о режимах отладки, исходные
данные и состав выходных результатов; язык комплексной динамичес-
кой отладки. Этап разработки программ включает: -я2 методические документыя0, содержащие правила: * записи программ на языках программирования; * организации взаимодействия программ; * размещение различных частей программы в памяти реализую-
щей ЭВМ; - я2спецификации требований на программные модулия0, позволяющая
определить структуру, функции модуля и его связь с другими моду-
лями ПС; спецификация модуля содержит: * заголовок, который целесообразно записывать в том же ви-
де, как он принят для языков программирования, т.е. включать в
него имя модуля, имена и типы формальных параметров и коммента-
рий; * паспорт модуля, содержащий описание всех входных и вы-
ходных глобальных данных, вызываемых модулей; сюда же включаются
данные о языке программирования и ориентировочные значения време-
ни исполнения и объем модуля; * функции модуля; - я2спецификации требований на глобальные модули данных я0сос-
тавляются одновременно со спецификациями на программные модули;
они содержат глобальные переменные, объединенные в структуры или
глобальные константы (формы аналогичны, но в спецификациях на мо-
дули данных отсутствует раздел функциональной схемы и содержатся
только описания данных или значения констант); - я2программы на языках программирования я0разрабатываются в со-
ответствии со спецификациями с применением методов структурного
программирования. После выполнения процедур записи программы в библиотеку про-
изводится контроль исходного текста для выявления ошибок, связан-
ных с нарушением правил разработки программ. я2Методы контроля программя0. Контроль состоит в проверке вход-
ной программы на соответствие некоторым формальным правилам; он
подразделяется на лексический, синтаксический и семантический. я1Логический контроль текста я0решает задачи выявления символов,
не принадлежащих к алфавиту входного языка и групп выделенных
символов, не принадлежащих к системным символам и символам конк-
ретного представления языка. Обычно лексический контроль совмеща-
ется с кодированием символов во внутреннее представление трансля-
тора. я1Синтаксический контроль я0проверяет входной текст на соответс-
твие синтаксису языка, заданному в его формальном описании. Одним
из методов является контроль бинарных отношений, т.е. выявление
таких пар символов, которые в языке рядом записаны быть не могут. я1Семантический контроль я0проверяет правильность применения
конструкций в конкретной записи. При программном методе проверка
правильности применения конструкций производится семантическими
программами, логика которых основана на неформализованных прави-
лах синтаксиса и семантики языка. я2Методы размещения переменных я0используются с применением
плотной упаковки в памяти многоразрядных ЭВМ. Используются такие
способы размещения при которых аппаратная выборка реализуется ми-
нимальным числом команд или за наименьшее время. Среди переменных, используемых в программе, выделяются вход-
ные и выходные параметры, которыми обмениваются программы, непос-
редственно вызывающие друг друга. Обмен информацией по входным и
выходным параметрам лучше всего реализуется при наличии я_магазиная.,
в который параметры загружаются и считываются в порядке, указан-
ном в списке формальных параметров в заголовке программы. При от-
сутствии магазина вводится соглашение о размещении параметров в
я_рабочем полея.. я2Масштабирование я0применяется при программировании выражений,
условий, операторов присваивания, когда часть или все элементы
выражения представлены в форме с я_фиксированной запятойя.. При масш-
табировании кроме согласования масштабов проверяются все крити-
ческие ситуации, которые возникают при операциях с фиксированной
запятой (потеря точности, переполнение, деление на нуль и т.д.). Используются два метода масштабирования: - рекурсивный, осуществляемый над парой операндов выражения,
связанных операцией, с учетом рангов и скобок; - полный при котором предварительно производится анализ все-
го выражения и определяется эквивалентное преобразование выраже-
ния с минимальным количеством операций масштабирования. я1Методы оптимизации программя0. Для получения при трансляции
программ с малым коэффициентом расширения (т.е. эффективно ис-
пользующих память и производительность реализующих ЭВМ), необхо-
димо осуществлять оптимизацию программ с использованием следующих
методов: ввод во входной язык средств, позволяющих программисту
осуществлять наиболее эффективную запись программ или давать
транслятору указания о методах оптимизации; ввод ограничений на
использование плохо программируемых конструкций входного языка
для конкретных ЭВМ или составление инструкций программисту по
применению языка в целях получения оптимальных программ, в част-
ности по включению последовательности операторов языка более низ-
кого уровня; включение оптимизирующих блоков в трансляторы. Авто-
матические машинно-независимые методы оптимизации включают: ло-
кальные, проводимые в пределах оператора (линейного участка прог-
раммы; глобальные, требующие построения графа программы и органи-
зации его просмотра по тем или иным признакам, именам переменных,
подвыражениям. я_Комплексированиея. включает в себя организацию взаимодействия
по информации и управлению при составлении комплекса программ из
отдельных программных модулей, разрабатываемых независимо. Комплексирование по информации осуществляется через глобаль-
ную память переменных и констант с единой идентификацией величин
во всех программах. В общем случае комплексирование приводит к необходимости пе-
ретрансляции части или всех программ после присвоения им новых
начальных адресов, что является весьма трудоемким процессом, тре-
бующим контроля правильности результатов этой процедуры. Чтобы
избежать перетрансляции, применяются абсолютные и относительные
методы. При я_абсолютных методахя. корректировка программ производится с
использованием вставок. В программу вставляются команды перехода
к вставке, содержащей команды изменения программы и команду возв-
рата. я_Относительные методыя. применяются с записью информации в па-
мять команд, что существенно упрощает проблему взаимного располо-
жения программ. Конкретно это воплощено в методах загрузки объек-
тных программ с редактированием связей. Редактированию подверга-
ются команды внутренних и внешних передач управления или команды,
использующие глобальные переменные и метки. Автономная перемещаемость программ может быть дополнена вза-
имной перемещаемостью. Для этого передача управления на другие
программы осуществляется через массивы вызова, содержащие либо
начальные адреса программ (в программе используются команды пере-
дачи управления по содержимому памяти или регистров), либо коман-
ды передачи управления на входы программ (в программе используют-
ся команды непосредственной передачи управления). При изменении
взаимного расположения программ изменяется только содержимое
массивов вызова, а в самих программах не производится редактиро-
вание внешних связей. Наиболее экономным методом взаимодействия программ по управ-
лению является метод непосредственной передачи управления на вход
вызываемой программы. В этом случае при изменении взаимного рас-
положения программ требуется обязательное редактирование команд
передачи управления вызываемой программе или адресных констант. Методы загрузки существенно влияют на время реализации заг-
рузки, которое имеет особенно большое значение при работе в диа-
логовом режиме. После корректировки программы в общем случае тре-
буется произвести перезагрузку всех программ с редактированием
внутренних и внешних связей. Загрузка модулей может производиться по нескольким стратеги-
ям: - в порядке их хранения в библиотеке; - в последовательности заранее присвоенных им номеров; - в соответствии с иерархией подчиненности. я_Средства автоматизации разработки программя.. Задача трансляции состоит в анализе разработанного програм-
мистом входного текста программы, записанного на языке программи-
рования, его контроле и преобразовании в выходной текст, которым
может быть либо программа для реализующей ЭВМ, либо промежуточный
язык. Система я_трансляционных средств я.составляется из взаимосвя-
занных трансляторов с каждого языка программирования. Такая сис-
тема позволяет исключить дублирование функций и компонент транс-
ляторов с языков нижних уровней в трансляторах с языков верхнего
уровня. Для получения малого расширения программ требуются я_транс-
я_ляторы с алгоритмических языков программированияя., имеющими мно-
гопросмотровую структуру. Транслятор с алгоритмического языка решает следующие задачи: - я_лексический контроль я.проводится при первом просмотре текс-
та; при этом выполняется ряд других функций транслятора,связанных
с выделенными в процессе синтаксического анализа конструкциями
языка, - составление списка глобальных переменных, меток и др.; - я_распределение памяти локальных переменных я.программных мо-
дулей производится транслятором по фиксированной для реализующей
ЭВМ логике с использованием типа, длины и размерности массива,
указанных в описании переменных; организация локальной памяти в
значительной мере определяется структурой ПЭВМ и зависит от спо-
собов адресации, наличия аппаратной выборки переменного числа би-
тов, системы модификации и т.д.; - я_семантический контроль я.использования величин в различных
конструкциях программы осуществляется после того, как определены
характеристики всех величин, применяемых в программе (локальных и
глобальных переменных, констант); - я_оптимизация программ я.проводится по тексту на входном языке
или на промежуточном языке, структура которого приспособлена для
решения данной задачи; - я_генератор команд я.формирует машинную команду из ее состав-
ляющих, информация о которых получена в результате трансляции
программы; любая машинная команда может быть представлена как со-
вокупность полей: код операции, операнд, база, индексация, приз-
наки типа адресации, признаки условий; - я_загрузчикя., используя редактор связей, производит комплек-
сирование либо всех объектных модулей, содержащихся в библиотеке,
либо части модулей, подлежащих отладке. Результатом трансляции программ является я_модулья.. Модули сос-
тоят из управляющей и информационной частей. Управляющая часть содержит данные, которые используются заг-
рузчиком для редактирования и загрузки программы (начальный адрес
трансляции, словари перемещений и внешних имен, различные призна-
ки, характеризующие структуру программы и методы загрузки. Информационная часть содержит программу модуля в кодах реа-
лизующей ЭВМ в форме, необходимой для работы загрузчика. Существуют следующие типы модулей: я_абсолютный я.- информацион-
ная часть модуля настроена на то место памяти, где он будет ис-
полняться; я_объектный я.- результат трансляции программы; в управля-
ющей части содержит информацию, по которой ее информационная
часть редактируется по внутренним и внешним связям; я_загрузочный я.-
результат объединения нескольких объектных модулей в один модуль,
готовый к исполнению. 12. Проектирование программного обеспечения: понятие кор-
ректности, эталона и сложности программ; программные ошибки
(24.1.). я_Понятие корректности или правильности я.подразумевает соот-
ветствие проверяемого объекта некоторому эталонному объекту или
совокупности формализованных эталонных характеристик и правил.
Корректность программы при проектировании наиболее полно опреде-
ляется степенью соответствия предъявляемым к ней формализованным
требованиям - я_программной спецификациия.. При отсутствии полностью
формализованной спецификации требований могут быть использованы
я_неформализованные представления я.разработчика, пользователя или
заказчика программ. Для установления корректности программ необходимы я2эталоныя0,
которым они соответствуют, а также я2методы проверки я0соответствия
программ эталонам и методы оценки степени корректности. я_Формализованные правилая. проектирования программ устанавлива-
ются стандартами и инструкциями подготовки текстов программ и их
структурного построения. Они включают описания языка программиро-
вания, правила оформления текстов программ и описания данных. я_Программные спецификациия. требований образуют иерархическую
структуру (технические предложения, ТЗ, эскизный, технический и
рабочий проекты). В них отражается совокупность эталонных харак-
теристик, функциональных критериев, свойств и условий, которым
должны соответствовать различные компоненты ПС. Вне условий, фор-
мализованных спецификациями, функционирование программ обычно не
определено. я_Тесты я.представляют собой частные реализации взаимосвязанных
исходных и результирующих данных. Эталоны этого вида формируются
на базе спецификаций и могут образовывать иерархические структу-
ры. Простейшими являются детерминированные тесты, в которых конк-
ретной совокупности исходных данных поставлена в соответствие со-
вокупность результирующих данных и определены точки в программе,
в которой эти совокупности данных должны проверяться. Под я_ошибкойя. понимается неправильность, погрешность или неу-
мышленное, невольное искажение объекта или процесса. Наличие
ошибки становится функцией как самого программного комплекса, так
и неформализованных требований его пользователей. Искажения в тексте программ (я_первичные ошибкия.) являются эле-
ментами,подлежащими корректировке. Искажения выходных результатов
исполнения программ (я_вторичные ошибкия.) вызывает необходимость вы-
полнения ряда операций по их локализации и устранению. При анализе программ имеется два аспекта их я_сложностия.: опре-
деление я_сложности процесса созданияя. программных компонент и опре-
деление я_сложности объектов разработкия. - программных модулей,
групп и комплексов программ, используемых данных и связей. Эти
аспекты тесно связаны и сложность объекта обычно определяется че-
рез трудоемкость процесса разработки. Понятие сложности ассоциируется с ресурсами, необходимыми
для решения соответствующей задачи. Для программ наиболее харак-
терными являются ресурсы, необходимые для их реализации, которые
определяют я_временную, программную и информационную сложностья.. я1Временная сложность программ я0в основном определяется алго-
ритмами, используемыми для решения задач. Несмотря на возрастание
быстродействия современных ЭВМ, имеется много задач, которые не-
возможно решить с помощью алгоритмов при необходимом объеме вход-
ных данных. При реальной производительности ЭВМ достижимое ка-
чество программ может определяться их временной сложностью. Это
означает, что длительность исполнения программ по тестовым данным
и длительность расчета эталонных значений возрастают так быстро,
что реальные ресурсы современных ЭВМ ограничивают допустимую пол-
ноту отладки и объем получаемых результатов. я1Программную сложность я0в простейшем случае можно оценить по
числу символов в тексте программы, необходимому для ее полного
описания на некотором алгоритмическом языке,или по числу операто-
ров (команд) при реализации программы на ЭВМ. Разнообразие алго-
ритмических языков и структур команд ЭВМ затрудняет обобщенные
оценки и сравнение программной сложности различных программ. Программная сложность в наибольшей степени определяет трудо-
емкость создания большинства крупных комплексов программ управле-
ния и обработки информации. я1Информационная сложность программ я0в первую очередь зависит
от количества типов и структуры данных, поступающих на вход и вы-
даваемых программой. Число различных видов операндов, используе-
мых в программе, достаточно полно характеризует ее информационную
сложность. Понятие информационной сложности включает емкость всех
ячеек памяти и регистров, к которым осуществляется обращение при
обработке операндов в процессе решения задачи. Сложность представления я_множества данныхя. может быть отражена
совокупностью сложности табулирования опорных данных и сложности
программ их декодирования для раскрытия всех значений. Программные модули являются наиболее простыми компонентами в
ПС, поэтому они наиболее доступны для количественного анализа
сложности. Исследование сложности программных модулей базируется
в основном на анализе внутренней структуры модулей. я1Структурная сложность программ я0определяется числом взаимо-
действующих компонент, числом связей между компонентами и слож-
ностью их взаимодействия. При функционировании программы характер ее поведения и раз-
нообразие связей входных и результирующих данных в значительной
степени определяются наборов я1путей-маршрутовя0, по которым исполня-
ется программа. Ограниченность ресурсов на разработку модулей приводит к це-
лесообразности я1выравнивания их структурной сложности я0и выделения
затрат на проверку в соответствии со сложностью каждого модуля. На сложность реальных модулей в наибольшей степени будет
влиять: положение модуля в иерархической схеме ПС; особенности и
тип структуры ациклической части модуля; наличие в модуле циклов
и их характеристики; характер вычислительного процесса в модуле;
характеристики нереализуемых путей исполнения программы. В сложных ПС используется три отличающихся типа модулей: - управляющие программы организации вычислительного процес-
са, расположенные на высших уровнях; они почти не выполняют вы-
числений, имеют на входе небольшое число преимущественно логичес-
ких переменных и выдают управляющие воздействия на вызовы функци-
ональных модулей (объем обычно невелик и составляет около 100
операторов на ассемблере); - основные функциональные программы - на средних уровнях;
наиболее сложные для разработки (эти модули имеют в среднем
200..300 операторов ассемблера или около 50 операторов на языке
высокого уровня, общее число глобальных переменных составляет в
среднем около 20 на каждый модуль); - стандартные программы для вычисления различных функций -
на нижних уровнях; наиболее просты при разработке; предназначены
для вычисления стандартных функций и решения типовых простейших
задач (имеют обычно простую структуру без циклов, объем - в пре-
делах 30..100 операторов на ассемблере, число переменных как на
входе, так и на выходе, составляет 3..5, а число маршрутов испол-
нения программы не превышает 10). При анализе сложности ПС в целом внутренняя сложность струк-
туры модуля и обработки в нем информации не учитывается, так же
как не учитывается сложность реализации операторов при анализе
сложности модулей. я_Сложность связей каждого модуля по управлению я.определяется
число вариантов возможных вызовов данного модуля из других моду-
лей и числом модулей, вызываемых из данного. При таком определе-
нии сложности каждая управляющая связь учитывается дважды: в вы-
зывающем и вызываемом модулях, что соответствует необходимости ее
проверки в обоих сопрягаемых модулях. я_Сложность информационных связей между модулями я.количественно
анализировать труднее, чем управляющие. Это обусловлено тем, что
возможны информационные связи между модулями, непосредственно не
связанными по управлению, а также тем, что каждая информационная
связь может значительно различаться сложностью в зависимости от
характеристик обменных данных. я_Структура программных группя., входящих в ПС, может быть отне-
сена к одному из двух видов. Характеристики взаимодействия между
модулями значительно различаются в зависимости от их расположения
в структуре ПС. я_Сложность связей каждого модуля по управлениюя. определяется
числом вариантов возможных вызовов данного модуля из других моду-
лей и числом модулей, вызываемых из данного. я_Сложность информационных связей между модулями я.количественно
анализировать трудные, чем управляющие. Это обусловлено тем, что
возможны информационные связи между модулями, непосредственно не
связанными по управлению, а также тем, что каждая информационная
связь может значительно различаться сложностью в зависимости от
характеристик обменных данных. я_Структура программных группя., входящих в ПС реального време-
ни, может быть отнесена к одному из двух видов. Первый вид струк-
тур близок к бинарному дереву, состоящему из 10..15 иерархических
уровней; число модулей на каждом уровне увеличивается по мере
снижения уровня, однако медленнее, чем в регулярном бинарном де-
реве. Структуры второго вида содержат один или несколько модулей,
вызывающих последовательно большое число (5..10) модулей более
низкого уровня. Характеристики взаимодействия между модулями значительно
различаются в зависимости от их расположения в структуре. я1Управляющие программные модули я0характеризуются слабой инфор-
мационной связью со всеми остальными. Они практически не обраба-
тывают информацию и не используют глобальные переменные. Возвраты
к управляющим программам производятся по стандартным правилам и
могут происходить из нескольких модулей каждой группы программ. я1Функциональные программные модули я0характеризуются широким
разнообразием характеристик взаимодействия. Число переменных,
считываемых из памяти для обработки модулем, в среднем больше,
чем число глобальных переменных. я1Стандартные программные модули я0относительно редко вызывают
другие программы (обычно такие программы только возвращают управ-
ление вызывающим программам). я_Типичные ошибки в программных комплексах.я. Статистические ха-
рактеристики ошибок могут служить ориентиром для разработчиков
при определении усилий на создание ПС. Характеристики ошибок в
процессе проектирования ПС помогают: оценивать реальное состояние
проекта и планировать трудоемкость и длительность до его заверше-
ния; рассчитывать необходимую эффективность средств оперативной
защиты от невыявленных первичных ошибок; оценивать требующиеся
ресурсы ЭВМ по памяти и производительности с учетом затрат на
устранение ошибок; проводить исследования и осуществлять адекват-
ный выбор показателей сложности компонент и ПС, а также некоторых
других показателей качества. я_Технологические ошибки я.документации и фиксирования программ
в памяти ЭВМ составляют 5..10 % от общего числа ошибок,обнаружи-
ваемых при отладке. Большинство их выявляется автоматически фор-
мализованными методами. я_Программные ошибки я.по количеству и типам в первую очередь
определяются степенью автоматизации программирования и глубиной
формализованного контроля текстов программ. Количество их зависит
от квалификации разработчиков, от общего объема комплекса прог-
рамм, от глубины логического и информационного взаимодействия мо-
дулей и от ряда других факторов. Программные ошибки можно классифицировать по видам использу-
емых операций на следующие группы: ошибки типов операций; ошибки
переменных; ошибки управления и типов. я_Алгоритмические ошибки я.значительно труднее поддаются обнару-
жению методами формализованного автоматического контроля. К ним
следует отнести прежде всего ошибки, обусловленные некорректной
постановкой функциональных задач, когда в спецификациях не пол-
ностью оговорены все условия, необходимые для получения правиль-
ного результата. Ошибки, обусловленные неполным учетом всех усло-
вий решения задач, являются наиболее частыми в этой группе и сос-
тавляют до 70 % всех алгоритмических ошибок и около 30 % общего
количества ошибок на начальных этапах проектирования. К алгоритмическим ошибкам следует отнести также ошибки свя-
зей модулей и функциональных групп программ. Их можно классифици-
ровать как ошибки некорректной постановки задач. Они составляют
6..8 % от общего количества. Особую часть алгоритмических ошибок составляют просчеты в
использовании доступных ресурсов вычислительной техники. Одновре-
менная разработка множества модулей различными специалистами зат-
рудняет оптимальное распределение ограниченных ресурсов ЭВМ по я_Системные ошибки я.определяются прежде всего неполной информа-
цией о реальных процессах, происходящих в источниках и потребите-
лях информации. На начальных стадиях проектирования не всегда
удается точно сформулировать целевую задачу всей системы, а также
целевые задачи основных групп программ, и эти задачи уточняются в
процессе проектирования. В соответствии с этим уточняются и конк-
ретизируются ТЗ или спецификации на отдельные программы и выявля-
ются отклонения от уточненного задания, которые могут квалифици-
роваться как системные ошибки. Детальный анализ проявления ошибок показывает их глубокую
связь с методами структурного построения программ, типом языка
программирования, степенью автоматизации технологии проектирова-
ния и другими факторами. Предложено несколько математических мо-
делей, описывающих основные закономерности изменения я_суммарного
я_количества вторичных ошибок я.в программах. Эти модели предназначе-
ны для оценки: надежности функционирования ПС в процессе отладки,
испытаний и эксплуатации; числа ошибок, оставшихся невыявленными
в анализируемых программах; времени, требующегося для обнаружения
следующей ошибки в функционирующей программе; времени, необходи-
мого для выявления всех ошибок с заданной вероятностью. Описаны несколько математических моделей, основой которых
являются различные гипотезы о характере появления ошибок в прог-
раммах. Эти гипотезы можно разделить на три основные группы. я_Первая группа допущений я.включает предположение о я1наблюдае-
я1мости искажений данныхя0, программ или вычислительного процесса,
обусловленных первичными ошибками в программах. Первичная ошибка,
являющаяся причиной искажения результата, либо фиксируется и исп-
равляется после завершения этапа тестирования, либо вообще не об-
наруживается, т.к. проявление ее последствий незначительно. я_Вторая группа допущений я.является основной и проверена интег-
рально по обобщенным характеристикам частости обнаружения ошибок
и дифференцированно путем анализа правомерности каждого допуще-
ния. Предусмотрены следующие допущения при построении экспоненци-
альной модели: я2интервалы времени я0между обнаруживаемыми искажения-
ми предполагаются я2статистически независимымия0; я2интенсивность про-
я2явления ошибок остается постояннойя0, пока не произведено исправле-
ние первичной ошибки или не изменена программа по другой причине;
я2интенсивность обнаружения ошибок пропорциональна суммарному числу
я2первичных ошибокя0, имеющихся в данный момент в ПС; я2частота исправ-
я2ления ошибок пропорциональна частоте их обнаруженияя0. я_Третья группа допущенийя. детализирует использование ресурсов
на корректировку программ и повышение их качества. Приведенные предположения позволяют построить экспоненциаль-
ную математическую модель распределении моментов обнаружения оши-
бок в программах и установить связь между интенсивностью обнару-
жения ошибок при отладке, интенсивностью проявления ошибок при
нормальном функционированию программ и числом первичных ошибок.
13. Методы распределения ресурсов, эффективность распределе-
ния производительности и памяти при проектировании автоматизиро-
ванных экономических информационных систем (АЭИС). При проектировании вычислительных и информационных систем
используются методы и средства распределения ресурсов, которые
лежат в основе организации вычислительного процесса и классифици-
руются по степени неопределенности информации о динамических ха-
рактеристиках поступления сообщений и их обслуживания. я2Методы распределения ресурсов первого типа я0характеризуются
полной априорной информацией о моментах поступления данных, дли-
тельностью их обработки, об объеме памяти,необходимом для хране-
ния исходных сообщений, программ и массивов данных, о связях меж-
ду программами. При этом составляется план последовательности ис-
пользования основных ресурсов системы на длительный интервал вре-
мени. Затраты на распределение ресурсов являются однократными и
могут быть произведены вне оперативного функционирования системы. я2В методах распределения ресурсов второго типа я0используются
статистические характеристики процесса поступления сообщений и
ресурсов для их реализации, позволяющие априорно классифицировать
сообщения на несколько групп, различающиеся параметрами. Каждую
из групп сообщений можно описать набором параметров и их статис-
тических распределений (или моментов распределений). Они доста-
точно полно характеризуют динамику поступления сообщений и пот-
ребность ресурсов для исполнения вызываемых ими программ. я2Методы распределения ресурсов третьего типа я0используются при
отсутствии параметра, позволяющего априори классифицировать сооб-
щения и ресурсы системы для их реализации. Отсутствие параметров,
пригодных для классификации и ранжирования вызываемых программ
приводит к тому, что ресурсы распределяются случайно, или выделя-
ются по мере поступления сообщений с учетом оперативных оценок
потребления ресурсов. Такие оценки позволяют перераспределять
поступившие сообщения и реализовывать в первую очередь те, кото-
рые требуют минимальных объемов памяти или производительности ВС. Чтобы получить результаты, пригодные для практического ис-
пользования, целесообразно разделить сложную вычислительную (ин-
формационную) систему на частные модели. я2Модель однопроцессорной системы без внешней памяти я0характер-
на для управления объектами с малым временем реакции. Она имеет
буферные накопители поступающей и выдаваемой информации и неогра-
ниченной оперативной памятью программ и данных. В таких системах
для хранения программ и констант применяется односторонняя па-
мять, обеспечивающая доступ к любой части программы. я2Модель иерархической внешней памяти я0рассматривается незави-
симо от взаимодействия с внешними абонентами. Многоуровневая па-
мять применяется в системах, где сравнительно велико допустимое
время реакции на внешние воздействия (порядка секунды) и требуют-
ся большие объемы памяти для хранения массивов данных и программ.
Производительность систем с многоуровневой памятью зависит от
скорости обмена данными между уровнями памяти (фазами обслужива-
ния) и методов использования памяти различных уровней. В я2моделях многомашинных и многопроцессорных системахя0 исполь-
зуются методы распределения ресурсов памяти и производительности
при параллельном исполнении программ. В этих моделях память одно-
уровневая и обслуживание заявок каждым процессором не учитывает
задержки при приеме и выдаче сообщений. Переход от моделей много-
машинных систем с автономной памятью каждого процессора к моделям
многопроцессорных систем зависит от степени связи устройств памя-
ти с соответствующими процессорами. Основой этих моделей является
многоканальная система обслуживания со связью между каналами в
процессе обслуживания заявок. Каждая из перечисленных моделей кроме временных показателей
и производительности характеризуется использованием некоторых
объемов оперативной памяти. Поэтому для каждой АЭИС необходимо
распределять ограниченный объем оперативной памяти на зоны раз-
личного назначения для того, чтобы получить экстремальное значе-
ние критерия качества функционирования системы. Большое количество параметров, влияющих на распределение па-
мяти, а также разнообразие показателей качества при определении
объема памяти и трудность их сведения к единому критерию усложня-
ют распределение памяти. Поэтому целесообразна декомпозиция обоб-
щенной модели для распределения памяти на ряд частных моделей,
непосредственно связанных с приведенными выше тремя моделями
распределения ресурсов системы. При распределении ресурсов ВС
конкретного назначения параметры подлежат экспериментальной или
теоретической оценке. я2Статические методы я0характеризуются возможностью больших зат-
рат производительности и памяти на оптимизацию распределения ре-
сурсов, т.к. оптимизация проводится однократно до начала рабочего
функционирования системы. При этом предполагается, что априорные
данные о параметрах, учитываемых при оптимизации, не изменяются в
течение всего времени функционирования при проведенном распреде-
лении ресурсов. Статическое распределение сводится обычно к реше-
нию экстремальной задачи методами математического программирова-
ния с соответствующими распределениями. Допустимость больших зат-
рат на распределение и высокая достоверность априорной информации
позволяют применять методы оптимизации и получать распределения
ресурсов, совпадающие с оптимальными или очень близкие к ним. я2Динамические методы я0распределения ресурсов реализуются в
процессе решения основных функциональных задач системы. Для этого
используется память и производительность системы; поэтому допус-
тимые затраты ресурсов системы на распределение ограничены и не
должны превышать получаемой экономии ресурсов. Чем достовернее
априорная информация, используемая при распределении, и чем доль-
ше она сохраняет свое значение, тем более точным может быть расп-
ределение ресурсов системы и тем дольше можно пользоваться ре-
зультатами оптимизации. Разовые затраты на распределение могут
быть повышены и его целесообразно проводить с применением более
точных методов. Для сокращения затрат на распределения при частом его прове-
дении подготавливаются правила, или я1дисциплины оперативной дис-
я1петчеризации я0обеспечивающие распределения, достаточно близкие к
оптимальным. Эти правила основываются на предварительных исследо-
ваниях различных методов распределения ресурсов. Многочисленные
технические ограничения и недостоверность априорной информации
приводят к целесообразности применения простейших правил и дис-
циплин, приближенно оптимизирующих распределение ресурсов. Основным показателем качества распределения ресурсов расс-
матривается эквивалентное изменение производительности системы
при различных дисциплинах по сравнению с простейшими эталонными
дисциплинами распределения ресурсов. Вычислительные ресурсы обычно оперативно предоставляются
преимущественно коротким по длительности реализации задачам, а
длинные решаются в течение нескольких квантов, последовательно
пропуская более короткие. Дисциплины ожидания и продолжения обс-
луживания после выделения очередного кванта времени на исполнение
рассматриваемой задачи различаются количеством очередей для ожи-
дания и методами изменения размера квантов в зависимости от дли-
тельности ожидания или количества уже использованных квантов. Реальные ограничения на производительность и другие харак-
теристики вычислительной системы (ВС) приводят к ожиданию резуль-
татов или к неполному решению задач. Неравноценность задач по до-
пустимому времени задержки или допустимой вероятности пропуска
решений, а также различия параметров ВС позволяют изменять ка-
чество решения задач выделением соответствующих ресурсов. я1Производительность вычислительной системы на некотором на-
я1боре задачя0 является критерием ее эффективности в целом и методов
распределения ресурсов в частности. Возникает задача определения
оптимальных параметров системы для решения некоторой совокупности
задач с учетом я1качества распределения ресурсов и затрат на их ре-
я1ализацию. я_я2Критерии эффективности распределения ресурсов по штрафамя.я0.
Ожидание результатов и пропуск решения задач можно описать неко-
торыми потерями эффективности или штрафами за то, что задачи не
решаются или решаются несвоевременно. В зависимости от назначения
и типа системы задержка может оцениваться либо по средней дли-
тельности ожидания результатов, либо по величине превышения фик-
сированного (допустимого) времени ожидания. При выборе метода распределения ресурсов возникает задача
минимизации возможных потерь информации путем построения рацио-
нальных дисциплин использования памяти, выборки данных для обра-
ботки и выдачи информации внешним абонентам. При этом естественно
ожидать, что более эффективные методы организации вычислительного
процесса являются и более сложными в реализации, т.е. их програм-
мы требуют большего числа команд и времени счета. Последнее осо-
бенно важно учитывать в относительно простых АЭИС, где затраты на
сложную организацию вычислительного процесса могут требовать зна-
чительной дроли быстродействия и памяти команд. я_я2Критерий эффективности организации вычислительного процесса
я_я2по эквивалентной производительности я.я0ВС. В большинстве случаев
удается определить только относительные значения коэффициентов
штрафа для различных типов заявок с точностью до некоторого сом-
ножителя. В общем случае большинство частных критериев распреде-
ления ресурсов можно свести к оценке изменения производительности
вычислительной системы, компенсирующего примененния любого метода
распределения ресурсов. Для определения эффективности приоритет-
ных дисциплин в качестве эталонной принимается бесприоритетная
дисциплина обслуживания заявок в порядке поступления. В зависимости от диапазона изменения значений длительностей
обслуживания и щтрафрв за ожидание (а также от загрузки и коэффи-
циентов вариации времени обслуживания) имеется возможность оцени-
вать я1рациональное количество приоритетнвх уровнейя0. Для исследо-
ванных моделей и приоритетных дисциплин целесообразно проводить
группирование типов заявок по приоритетным уровням в пределах
6..8 приоритетов для дисциплины с относительными проритетами и
10..16 - для дисциплины с абсолютными приоритетами. Диспетчеризация с относительными или или абсолютными прио-
ритетами дает заметный выигрыш в эквивалентной производительности
ЭВМ при весьма ограниченном количестве приоритетных уровней, ког-
да длительности решения отдельных задач или штрафы за ожидание их
результатов различаются не менее чем на порядок. При этом число
выделяемых приоритетных уровней целесообразно ограничивать в пре-
делах 10..15, т.к. дальнейшее увеличение числа приоритетов прак-
тически неэффективно. Наиболее эффективна приоритетная диспетче-
ризация при загрузке ЭВМ в пределах 0,7..0,9. При малых загрузках
приоритетные дисциплины вырождаются в обслуживание по мере пос-
тупления сообщений. При загрузке, приближающейся к единице, резко
возрастает длительность ожидания низкоприоритетных сообщений, что
приводит к падению эффективности любых приоритетных дисциплин. Таким образом, при проектировании приоритетной диспетчири-
зации и выборе дисцимплин необходимо анализировать характеристики
решаемых в ЭВМ задач и оценивать достигаемую эффективность мето-
дов диспетчиризации. Для дисциплин с абсолютными приоритетами
важно учитывать затраты времени на прерывание решаемых задач. Оценки эффективности с учетом различия затрат на единицу
времени до и после прерывания показывают, что использование дис-
циплин с с прерыванием целесообразно в том случае, когда штраф за
ожидание в прерванном состоянии не очень сильно (не более чем в
2..3 раза) увеличивается по сравнению со штрафом за ожидание до
начала обслуживания и за время обслуживания. При дисциплинах с прерыванием необходимо учитывать измене-
ние длительности ожидания в очереди и длительности обслуживания
как как прерывающих, так и прерываемых программ вследствие затрат
на переключение программ. С учетом этих поправок могут сопостав-
ляться дисциплины с прерыванием и без прерывания обслуживания.
Дисциплины с прерыванием, характеризующиеся более частым переклю-
чением программ, более чувствительны к изменению затрат на каждое
переключение программ. По мере увеличения затрат на каждое перек-
лючение программ дисциплины с прерыванием могут сравниваться по
эффективности с более простыми и последние могут оказаться более
эффективными. Прерывния и затраты времени на переход к вычислениям по но-
вой программе приводят к увеличению суммарнного штрафа за пребы-
вание заявок в системе, что обусловлено в основном возрастанием
загрузки при интенсивных прерываниях. Для дисциплины с относительными приоритетами переключения
происходят реже и средние затраты на переход к очередной програм-
ме меньше чем при абсолютных приоритетах. Для исключения связи во времени процессов приема сообщений и
их обработки применяются буферные накопители, объем которых огра-
ничен. При выдаче сообщений внешними абонентами буферные накопи-
тели используются для временного хранения сообщений, необходимого
из-за несинхронной подготовки сообщений и освобождения каналов
связи. Эффективность использования ограниченных буферных накопи-
телей зависит прежде всего от их структурного построения и расп-
ределения имеющейся памяти на зоны. Кроме того, на эффективность
существенно влияют дисциплины заполнения памяти заявками-сообще-
ниями и их передачи из накопителей на обработку. Основной характеристикой, используемой для оценки объема бу-
ферной памяти, а также для определения эффективности накопителей
и оптимизации их объемов, является я1вероятность потери сообщений
я1из-за переполнения памятия0. В реальных АЭИС загрузка и дисперсия
длительности обслуживания являются случайными дисциплинами и из-
вестны всегла с некоторой точностью, которая и определяет случай-
ную ошибку вероятности потери. Структура систем выдачи сообщений из систем в большинстве
случаев характеризуется наличием нескольких потребителей информа-
ции, каждый из которых должен получать сообщения только опреде-
ленного вида. Таким образом, системы выдачи могут рассматриваться
как я2непонодоступные многоканальные я0системы, в то время как орга-
низация вычислительного процесса анализируется на моделях я2однока-
я2нальныхя0 систем массового обслуживания. При приеме разнородных сообщений по их характеристикам может
быть определена шкала упорядочения сообщений различных типов.
Распределение по приоритетам производится путем последовательного
анализа пар типов заявок и рекуррентным распределением по их при-
оритетным уровням. Для сравнения различных методов распределения ресурсов в ВС
при ограниченной буферной памяти возможно их сопоставление по из-
менению объема буферной памяти. я_Эффективность распределения на зоны буферной памяти для при-
я_ема сообщений при бесприоритетной дисциплиныя.. В этом случае ос-
новным варьируемым параметром является соотношение между объемами
зон памятип для заявок различных потоков. Неравномерным распреде-
лением памяти по зонам для сообщений одних типов за счет других
можно добиться того, чтбы вероятности потери для сообщений раз-
личных типов распределялись таким образом, чтобы суммарное значе-
ние штрафа падало по сравнению со случаем равенства вероятностей
потери всех типов сообщений при том же суммарном объеме памяти. В реальных вычислительных системах (каковыми являются и
АЭИС) заявки-сообщения на включение программ определенного типа
весьма часто характеризуются различным объемом информации и тре-
буют для хранения одного сообщения различного количества ячеек
оперативной памяти. В тех случаях, когда это различие существенно
больше 20..30 % для каждого типа сообщения, использование единой
буферной памяти с заполненеием свободных мест вызывает дополни-
тельные потери времени при их записи, т.к. приходится учитывать
не только наличие, но и объем свободного места. При наличии сооб-
щений нескольких типов, существенно различающихся по обЪему, раз-
деление буферной памяти на зоны по типам сообщений позволяет пол-
ностью использовать объем каждой зоны и может давать значительные
преимущества зональному построению буферной памяти. я_Эффективность приоритетных дисциплин по использованию огра-
я_ниченной буферной памяти для приема сообщенийя.. Для сравнения раз-
личных методов распределения буферной памяти при приоритетном
обслуживании за эталонное значение принимается объем буферной па-
мяти, необходимый при единой зоне для всех сообщений и бесприори-
тетном обслуживании заявок в порядке поступления. Соответствующие
оценки получены методом статистческого моделирования двух пото-
ков. я_Принципы распределения многоуровневой памятия.. Использование
иерархической многоуровневой памяти в ВС позволяет существенно
снизить суммарную стоимость хранения больших объемов информации
при некотором допустимом снижении быстродействия ВС. Запоминающие
устройства используются в порядке убывания быстродействия и стои-
мости хранения единицы информации и соответственно в порядке воз-
растания объема хранимых данных. Оптимизация построения иерархи-
ческой памяти всегда ориентирована на на определенную специфику
исполдьзуемых программ и данных.
14. Системы автоматизации проектирования автоматизированных
экономических информационных систем (АЭИС); состав инструменталь-
ных средств для различных уровней автоматизации разработки АЭИС;
структурная схема комплексной системы автоматизации сложных АЭИС
(26.1.). Автоматизация технологии проектирования информационных сис-
тем реализуется в я2инструментальных системах автоматизациия0. Требо-
вания к которым зависят от сложности объектов разработки, имею-
щихся ресурсов создания систем, ряда конструктивных и организаци-
онных факторов, и состоят в следующем: снижение общей трудоемкос-
ти, длительности создания АЭИС и повышение производительности
труда специалистов в коллективе разработчиков; обеспечение высо-
кого качества и надежности функционирования создаваемых и сопро-
вождаемых АЭИС; комплексная автоматизация коллективной разработки
АЭИС большого объема и высокой сложности; обеспечение унифициро-
ванной технологии разработки и сопровождения АЭИС для реализующих
ЭВМ широкого класса; обеспечение эффективного использования ре-
сурсов памяти и производительности реализующих ЭВМ. На основе этих требований, а также теоретических исследова-
ний и опыта разработки сложных АЭИС сформировались технологичес-
кие принципы, которые состоят в следующем: я2Комплексная автоматизация регламентированного технологичес-
я2кого процесса я0разработки и сопровождения АЭИС, определяющая авто-
матизацию всех функционально связанных этапов и операций техноло-
гического процесса. Это достигается созданием общей базы данных
проектирования, в которой хранятся все компоненты АЭИС во всех
формах представления. я2Адаптивность кросс-технологии я0предполагает создание универ-
сальных кросс-систем автоматизации разработки АЭИС, которые наст-
раиваются на характеристики реализующих ЭВМ и и обеспечивают еди-
ную унифицированную технологию. я2Разделение труда и регламентация результатов этапов работ
являются основой для разграничения ответственности специалистов
разной квалификации за качество конечного продукта - модуля прог-
раммы, системы и т.д. я2Долгосрочное и оперативное планирование работя0, т.е. система-
тическое поэтапное планирование работ коллектива на основе имею-
щихся ресурсов. я2Рациональное диалоговое общение я0со средствами автоматизации
предполагает комфортное общение специалистов с инструментальными
средствами (безбумажная технология). Принципы проектирования определяют построение АЭИС и методы
достижения их высокого качества, которые состоят в следующем: я2Модульно-иерархическое структурное построение я0предполагает
организацию связей между модулями. одновременно этот принцип оп-
ределяет необходимость упорядочения внутренних структур модулей,
массивов данных и системы в целом. я2Переносимость компонент я0определяет реализацию многократного
использования разработанных компонентов, в т.ч. для различных ре-
ализующих ПЭВМ. я2Раздельная компиляция я0модулей на основе упреждающей разра-
ботки БД предполагает первоочередную разработку описаний глобаль-
ных данных, хранение этих описаний в базе данных проектирования,
и организацию на этой основе независимой компиляции модулей. я2Эффективное использование памяти я0стимулирует использование
при проектировании методов, минимизирующих затраты ресурсов памя-
ти реализующей ЭВМ. я2Систематическое описание компонент я0приводит к созданию сис-
темы взаимосопряженных языков проектирования разного уровня и
назначения, позволяющих регулярно описывать различные свойства
АЭИС и ее компонент на разных этапах разработки и сопровождения. я2Многоэтапная систематическая отладка я0компонент АЭИС призвана
обеспечить корректность и надежность создаваемой системы путем
последовательного применения методов тестирования и отладки. я2Автоматическое документирование в соответствии с нормативны-
я2ми требованиями я0определяет создание средств автоматизации выпуска
эксплуатационной и сопровождающей документации на АЭИС и ее ком-
поненты, соответствующей требованиям стандартов и нормативов. При проектировании и разработке конкретных АЭИС состав
средств автоматизации может существенно изменяться. В зависимости
от характеристик создаваемой АЭИС целесообразна различная номенк-
латура применяемых средств автоматизации, общий набор которых
приводится ниже. Системный анализ и проектирование алгоритмов: моделирование
алгоритмов разных классов; моделирование внешней среды; определе-
ние эффективности разрабатываемых систем. Структурное проектирование: обработки спецификаций на АЭИС и
группы программ; описание структуры АЭИС; оценки производитель-
ности ПЭВМ для реализации АЭИС; моделирования функционирования
АЭИС на параллельных вычислительных системах. Подготовка технологических средств подготовка базы данных
проекта АЭИС; адаптация системы автоматизации к конкретным усло-
виям разработки АЭИС; контроля и управления процессом разработки; Разработка программ: управления базой данных проекта; инте-
рактивного управления средствами автоматизации; обработки прог-
раммных спецификаций; транслятор с ассемблера; макрогенератор;
транслятор с языка высокого уровня. Отладка программ в статике: статического контроля коррект-
ности текста и структуры программ; планирование тестирования;
символической отладки; отладки с исполнением программ в объектном
коде; комплексирования и контроля связей модуля; расчета длитель-
ностей исполнения программ; генератор стохастических тестов; кон-
фигурационного контроля. Комплексная динамическая отладка: контроля исполнения прог-
рамм в реальном масштабе времени; моделирования внешней среды;
обработки результатов отладки в реальном времени; подготовки от-
четов об ошибках. Выпуск машинных носителей и документирование: выпуска конс-
трукторской и эксплуатационной документации; выпуска технологи-
ческих документов; изготовления и контроля машинных носителей;
учета и внесение измерений в документы и машинные носители; ана-
лиза характеристик программ и процесса разработки. Испытания системы: измерения характеристик функционирования
АЭИС в реальном времени; учета и анализа версий АЭИС; имитации
расширенных характеристик внешней среды; производства и контроля
качества тиражируемых АЭИС. Указанные средства обеспечивают минимальные затраты на соз-
дание АЭИС, заданные сроки разработки или оптимизацию техни-
ко-экономических показателей. Их использование обусловлено воз-
можностями и дифференцируется в зависимости от уровня автоматиза-
ции (предусмотрено 5 соответствующих уровней). Переход от одного
уровня к другому, более высокому, дает возможность повысить сте-
пень автоматизации примерно в 1.5 раза. Систему автоматизации АЭИС можно условно разделить на следу-
ющие крупные компоненты: базу данных проектирования; организующую
систему; систему автоматизации системного анализа; систему авто-
матизации программирования; систему автоматизации отладки на тех-
нологической ЭВМ; систему автоматизированного выпуска документа-
ции; систему имитации внешней среды и статистической обработки
результатов функционирования программ; систему программ отладки
на реализующей ЭВМ. Для автоматизации разработки используются три типа ЭВМ; реа-
лизующая, осуществляющая исполнение разработанных программ в ре-
альной системе обработки экономической информации; технологичес-
кая, предназначенная для размещения основных средств системы ав-
томатизации разработки; моделирующая, реализующая средства имита-
ции внешней среды и обработки результатов отладки. я_я2Выходными данными я.я0системы автоматизации разработки (САР) яв-
ляются отработанные программы на машинных носителях, результаты
обработки тестовых данных комплексом программ, обобщенные резуль-
таты функционирования АЭИС и отпечатанные документы различного
назначения. Отработанные на технологической ЭВМ компоненты систе-
мы подготовляются и кодируются на машинных носителях информации
для ввода в реализующую ЭВМ. я_я2База данных я.я0предназначена для упорядоченного хранения и кор-
ректировки большого количества информации, отражающей состояние и
изменение разрабатываемой системы. В БД накапливается вся исход-
ная, промежуточная и результирующая информация, характеризующая
АЭИС и ее переменные, особенности системы, а также процесс ее
создания. В библиотеке проекта накапливаются данные, необходимые
для описания характеристик системы и для распределения памяти ар-
хивов, с учетом решаемых функциональных задач и характеристик
создаваемой АЭИС. Библиотеки технологических и промежуточных дан-
ных предназначены для длительного хранения информации, подготав-
ливаемой средствами САР. В отдельной библиотеке накапливаются и
обобщаются данные о состоянии процесса разработки компонент ин-
формационной системы. я_я2Организующая система я.я0предназначена для интерактивного управ-
ления режимами функционирования САР по директивам пользователей,
для организации накопления, хранения и обработки информации в БД.
В состав этой системы включены средства, необходимые для подго-
товки всей системы к конкретным условиям применения, и средства
контроля и обобщения данных о ходе проектирования АЭИС. Для связи пользователей с системой автоматизации и для рас-
шифровки их директив служит монитор. Средства управления БД обес-
печивают контроль и корректировку информации на магнитных носите-
лях, а также каталогизируют всю поступающую и изменяемую информа-
цию. Для управления процессом разработки сложной АЭИС используют
средства, осуществляющие сбор, обобщение и редактирование информа-
ции о состоянии разработки компонент АЭИС и о результатах дея-
тельности каждого специалиста-разработчика. я_я2Система автоматизации системного анализая.я0. Состав средств
этой системы и методы решения задач полностью зависят от назначе-
ния, функций и области применения разрабатываемой АЭИС. я_я2Система автоматизации программирования я.я0обеспечивает трансля-
цию программ с нескольких входных языков программирования. Транс-
ляция и обработка спецификаций производится для проверки в про-
цессе разработки корректности межмодульных связей и контроля со-
ответствия текстов программ на языках программирования исходным
спецификациям. В системе применяется группа взаимодействующих
трансляторов с языка программирования разного уровня. Программный
модуль может быть первично записан на языке высокого уровня, на
языке макрокоманд или на автокоде (ассемблере). Для оттранслированных программ формируются паспорта и лис-
тинги, тексты в объектном коде записываются в библиотеку загру-
зочных модулей. Окончательное редактирование связей и присвоение
исполнительных адресов производится загрузчиком. я_я2Система автоматизации отладки я.я0на технологической ЭВМ содер-
жит средства для символической отладки программ по исходным текс-
там, а также для детерминированной и статистической отладки в
процессе исполнения протранслированных программ. Для структурного
контроля, а также для расчета длительностей исполнения программ и
автоматизированного построения блок-схем используются графовые
модели программных модулей. я_я2Система автоматизированного выпуска документации и машинных
я_я2носителей я.я0на системы обеспечивает подготовку и изготовление доку-
ментов трех типов: конструкторских, необходимых для для произ-
водства, контроля и эксплуатации АЭИС; технологических, использу-
емых в процессе разработки, испытаний и сопровождения АЭИС; исс-
ледовательских, необходимых для анализа проектируемой системы и
процесса ее разработки с целью повышения качества и снижения тру-
доемкости создания. Для регистрации на машинных носителях служат средства, обес-
печивающие перенос разработанной АЭИС или ее компонент из техно-
логической ЭВМ в реализующую. Этот перенос в ряде случаев может
быть произведен путем непосредственной передачи информации по те-
лекодовым каналам связи. я_я2Система программной имитации внешней средыя.я0. Имитация сообще-
ний внешних абонентов проводится в два этапа: имитация эталонных
данных и имитация случайных искажений и ошибок. Эти данные затем
объединяются и обеспечивают подготовку сообщений с характеристи-
ками, максимально приближающимися к реальным. Специальные имита-
ционно-моделирующие стенды, близкие к реальной аппаратуре имити-
руемых систем, позволяют дополнить автоматическую имитацию основ-
ной массы сообщений реальными данными от человека, контролирующе-
го функционирование такой системы. Еще один способ имитации исходных данных сводится к записи
сообщений, полученных от реальных объектов в процессе натурных
экспериментов. я_я2Система обработки результатовя.я0. Оперативная обработка резуль-
татов экспериментов производится по упрощенным алгоритмам, требу-
ющим малого времени ЭВМ и обеспечивающая сохранение реального
масштаба времени. Обобщающая обработка результатов может быть
произведена вне реального времени исполнения программы после за-
вершения одного или серии экспериментов. Методика обработки и анализа результатов экспериментов при
испытаниях системы должна обеспечивать единство взглядов заказчи-
ка и разработчика системы и не допускать искажений интерпретации
результатов за счет неоднозначности методики. я_я2Система динамической отладки я.я0на реализующей (специализиро-
ванной) ЭВМ функционирования АЭИС в реальном времени управляется
внешними и внутренними сообщениями. В соответствующих системах,
реализуемых на на универсальных (П)ЭВМ, активно используется ряд
компонент, входящих в типовые операционные системы и пакеты прик-
ладных программ, широкого назначения (системы управления БД,
трансляторы с языков программирования, текстовые редакторы, доку-
ментаторы и т.д.). Эти компоненты целесообразно комплексировать в
единую систему автоматизации, поддерживающую определенную техно-
логию проектирования. Систему дополняют средствами обработки спе-
цификаций требований, организации и проведения тестирования,
комплексирования программ, контроля и управления разработкой и
другими средствами автоматизации. В результате может быть сформи-
рована система, поддерживающая весь процесс создания АЭИС. Особенности проектируемой АЭИС необходимо учитывать в техно-
логии и средствах автоматизации, которые предполагается приме-
нять. Затраты на подготовку системы автоматизации к условиям
конкретной разработки обычно невелики и составляют 1..2 % от тру-
доемкости всей разработки. Совокупность работ, обеспечивающая
адаптацию машинно-зависимых компонент, составляет: я2подготовка языков программированияя0: я1подготовка автокода я0включает формирование его лексики, син-
таксиса и семантики; проводя последовательную стандартизацию ком-
понент АЭИС, можно получить различную степень унификации операто-
ров автокода и, как следствие, различный объем работы по их фор-
мированию; я1подготовка макроязыка я0состоит из разработки системных и ло-
кальных макрокоманд; решение первой задачи обеспечивает формиро-
вание конкретных наборов автокодных команд, которые подставляются
на место системных макрокоманд в процессе макрогенерации; вторая
задача связана как с формированием самих локальных макрокоманд,
так и их макроопределений; я1алгоритмический язык я0является машинно-независимым языком и
обычно не нуждается в подготовке; однако в конкретных разработках
используются различные диалекты алгоритмического языка, адаптиро-
ванные к специфическим условиям применения. я2подготовка базы данных проектирования я0обеспечивает выбор
объемов библиотек, входящих в базу данных; состав библиотек опре-
делен в кросс-системе и закрепляется для разработки любых АЭИС.
Кроме того на этом этапе осуществляется запись в библиотеку мак-
роопределений системных макрокоманд. я2подготовка машинно-зависимых компонент я0является наиболее
сложной и трудоемкой задачей, включающей: я1подготовка транслятора с автокода я0включает изменение прог-
рамм, реализующих все его основные функции; я1макрогенераторя0, как правило, не является объектом подготов-
ки, т.к. в большинстве случаев он реализует лишь операции подста-
новки макроопределений; я1подготовка загрузчика я0связана с изменением программ, осу-
ществляющих следующие функции; я1компилятор алгоритмического языка я0выполняется по многопрос-
мотровой схеме и включает: формирование машинных команд; масшта-
бирование данных; распределение памяти под данные; распределение
памяти под программы. я1система автоматизации отладки я0является машинно-зависимой
компонентой системы; в общем случае включает модели процессора
(интерпретатор) и схемы прерывания, обмена данными с внешними
абонентами, службы времени, обращения к общей памяти. я2проверка подготовки я0кросс-системы состоит в установлении
факта ее работоспособности. В общем случае для проверки применя-
ется метод детерминированного тестирования, в связи с чем в зада-
чу подготовки входит изготовление тестов и эталонов. Для этого
используется специальное программное обеспечение, представляющее
собой набор пакетов, контрольных заданий и контрольных задач, а
также эталонных распечаток, позволяющих сравнить результат работы
эталона с результатом работы его копии. 15. Основные понятия надежности автоматизированных экономи-
ческих информационных систем (АЭИС); методы повышения надежности
функционирования АЭИС; методы проектирования систем с заданными
надежностью (25.1.). Надежность сложных ПС определяется двумя факторами: я1надеж-
я1ностью компонент и ошибками в конструкциия0, допущенными при проек-
тировании. Доминирующим является второй фактор . Следует определить фундаментальные понятия теории надежности
применительно к анализу характеристик функционирования программ. я_Отказ при использовании программя.. Понятие отказа связано с
нарушением работоспособности изделия и его соответствия требова-
ниям технической документации. Отказ при исполнении программ мо-
жет проявиться как следствие: нарушения кодов записи программ в
памяти команд; стирания или искажения данных в оперативной или
долговременной памяти ЭВМ; нарушения нормального хода вычисли-
тельного процесса. Во всех случаях отказы приводят к прекращению
выдачи информации и управляющих воздействий или к значительному
искажению ее содержания и темпа выдачи. я_Сбой при исполнении программя.. Понятие сбоя в теории надеж-
ности трактуется как самоустраняющийся отказ, не требующий внеш-
него вмешательства для замены отказавшихся компонент. Основной
принцип классификации сбоев и отказов - разделение по я_временному
я_показателю длительности восстановления я.после любого искажения
программы,данных или вычислительного процесса. Классификация
программных сбоев и отказов по длительности восстановления приво-
дит к необходимости анализа следующих динамических характеристик
внешней среды и временных характеристик функционирования прог-
рамм: инерционности объекта, являющегося источником или потреби-
телем информации; среднего темпа или периодичности решения задач
по обработке информации для данного объекта; допустимой длитель-
ности ожидания отклика или времени реакции ЭВМ от момента поступ-
ления исходных данных до момента выдачи обработанных результатов. я_Правильный и надежный комплекс программя. характеризуется ве-
роятностью попадания в область исходных данных, предусмотренную
требованиями спецификации. я2Надежная программа я0обеспечивает низкую вероятность отказа в
процессе реального функционирования. Быстрое реагирование на ис-
кажения программ, данных или вычислительного процесса и восста-
новление работоспособности за время, меньшее, чем порог между
сбоем и отказом. я_Восстановлениея.. Отсутствие физического разрушения компонент
функционирующего ПС позволяет добиваться высокой автоматизации
программного восстановления. Для решения этой задачи в ПС должны
быть средства, позволяющие: проводить систематический контроль и
обнаруживать аномалии процесса функционирования или состояния
программ и данных; диагностировать обнаруженные искажения; выби-
рать методы и средства оперативного восстановления; реализовывать
оперативное восстановление нормальной работоспособности; регист-
рировать происшедший сбой или отказ и обобщать с данными предыду-
щих искажений для выявления систематических случаев, требующих
доработки программ или аппаратуры. Реализация средств с такими функциями осуществляется за счет
введения я2избыточности я0в программы, данные и процесс функциониро-
вания ПС: программной, включающей все программные компоненты,
предназначенные для контроля, обнаружения, диагностики и восста-
новления ПС; информационной, заключающейся в дублированном хране-
нии данных и средств кодовой помехозащиты информации; временной,
состояшей в выделении необходимых резервов процессорного времени
ЭВМ на исполнение программ, обеспечивающих оперативный контроль и
восстановление (рестарт) функционирования ПС. я_Критерий надежности программя.. В зависимости от целевого наз-
начения систем для анализа показателей надежности их целесообраз-
но разделить на два класса: невосстанавливаемые и восстанавливае-
мые. Для оценки надежности восстанавливаемых систем (программ)
необходимо знать характеристики многократных отказов и восстанов-
лений. Процесс восстановления достаточно полно описывается пока-
зателями: вероятностью восстановления за некоторое время; плот-
ностью распределения времени восстановления и средним временем
восстановления. Объединение характеристик отказов и восстановле-
ний производится в следующих критериях: я2наработка на отказя0 и я2ко-
я2эффициент готовностия0. На надежность функционирования ПС влияют факторы, вызывающие
сбой или отказ при исполнении программы: искажения исходной ин-
формации, поступающей от внешних абонентов; самоустраняющиеся от-
казы или сбои в аппаратуре ЭВМ; невыявленные ошибки в программах.
Первопричинами искажения данных, поступающих от внешних абонен-
тов, могут быть: искажения данных на первичных носителях информа-
ции при их подготовке; сбои и частичные отказы в аппаратуре ввода
данных с первичных носителях информации; шумы и сбои в каналах
связи при передаче сообщений по телекодовым линиям связи; сбои и
частичные отказы в аппаратуре передачи или приема телекодовой ин-
формации; потери или искажения сообщений в огранеченных буферных
накопителях ЭВМ; ошибки в документах, используемых для подготовки
данных, вводимых в вычислительную систему. При искажении вычислительного процесса или данных задача
состоит в максимально быстром обнаружении искажения, в возможно
точной классификации типа уже имеющихся и возможных последствий
искажений, а также в проведении мероприятий, обеспечивающих быст-
рое восстановление нормального функционирования ПС. Под я_временной избыточностьюя. понимается использование неко-
торой части производительности ЭВМ для контроля исполнения прог-
рамм и восстановления вычислительного процесса. Для этого при
проектировании программ должен предусматриваться запас производи-
тельности, который затем используется для контроля и надежности и
повышения надежности функционирования. Для диагностики искажений
и операций восстановления требуется в общем случае небольшой ин-
тервал времени, который выделяется либо за счет резерва, либо за
счет сокращения времени решения функциональных задач. я_Информационная избыточностья. состоит в дублировании накоплен-
ных исходных и промежуточных данных, обрабатываемых ПС. Избыточ-
ность используется для сохранения достоверности данных, которые в
наибольшей степени влияют на нормальное функционирование программ
или требуют значительного времени для восстановления; она может
способствовать не только обнаружению искажений, но и устранению
ошибок. Для этого данные защищают двух-трехкратным дублированием
с соответствующей дисциплиной контроля сохранности и периодичес-
кого обновления. я_Программная избыточностья. используется для контроля и обеспе-
чения достоверности наиболее важных результатов обработки инфор-
мации. Она заключается в применении в ПС нескольких вариантов
программ, различающихся методами решения некоторой задачи или
программной реализации одного и того же метода. С точки зрения построения защиты можно выделить следующие
типы искажения результатов: - приводящие к прекращению выполнения основных функций ПС на
длительное или неопределенное время; последствия могут проявлять-
ся в следующих видах: зацикливание, т.е. последовательная повто-
ряющаяся реализация определенной группы команд, не прекращающаяся
без внешнего вмешательства; останов и прекращение решения функци-
ональных задач; искажение процессов взаимного прерывания прог-
рамм, приводящее к блокировке возможностей некоторых типов преры-
ваний; прекращение или значительное снижение темпа решения неко-
торых некоторых задач вследствие перегрузки ЭВМ по пропускной
способности; значительное искажение или потеря накопленной инфор-
мации о текущем состоянии внешней среды; - кратковременно, но значительно искажающие отдельные ре-
зультаты по их смысловому содержанию или величине; последствия
могут проявляться в следующих видах: пропуск модуля или группы
программ; выход на программы или их части, резко искажающие ре-
зультаты; выход на программы или их части, резко снижающие ре-
зультаты; - мало и кратковременно влияющие на результаты, выдаваемые
программами; этот тип ошибок в среднем мало искажают общие ре-
зультаты, однако их большая концентрация может существенно влиять
на функционирование ПС. я1Защита от зацикливанияя0 в программах предотвращает искажение
реальных подготовленных циклов, а также образование непредусмот-
ренных (ложных) циклов. Автоматическое обнаружение зацикливания наиболее просто
просто производить при наличии вы составе аппаратуры ЭВМ счетчика
относительного времени, пригодного для подсчета длительности вре-
менных интервалов. Контролировать зацикливания можно также путем
периодического прерывания вычислительного процесса и анализа те-
кущего времени. Причиной зацикливания могут быть не только ошибки в програм-
ме и искажения исходной информации, но и сбои в аппаратуре. При-
чиной многократных зацикливаний с различными исходными данными
является скорее всего частичный отказ в аппаратуре или искажения
информации в процессе управления. я1Защита от останова я0по методам принципиально близка к защите
от зацикливания. Останов ЭВМ происходит либо из-за ошибки при
формировании команды (частичный отказ или сбой), либо из-за оши-
бок в программе, приводящей к попаданию на участок программы, со-
держащий команду останова. Автоматическое обнаружение останова
может производиться аналогично обнаружению зацикливания. я1Защита от искажения взаимного прерывания программя0, приводя-
щих к возможности взаимной блокировки некоторых типов прерываний,
осуществляется в основном аппаратными методами. Для защиты от та-
ких программных ошибок, а также от от аппаратных сбоев при преры-
ваниях должны предусматриваться программный контроль выполнения
прерываний и периодический контроль наличия взаимодействия со
всеми абонентами. я1Защита от ошибок, приводящих к пропуску программ или их су-
я1щественных частейя0, производится в основном методами контроля:
ключевых кодов, определяющих перечень программ, которые должны
быть включены; предшествования программ и изменения отдельных пе-
ременных. При обнаружении пропуска программы при ее завершении
производится повторное включение всей функциональной группы. В
отдельных случаях осуществляется автоматическое принудительное
включение пропущенной программы. я1Защита от перегрузки ЭВМ по пропускной способности я0предпола-
гает обнаружение и снижение влияния последствий алгоритмических
ошибок, обусловленных неправильным определением необходимой про-
пускной способности ЭВМ. Перегрузки могут быть также следствием
неправильного функционирования источников информации и превышения
интенсивности потоков сообщений. Последствия сводятся к прекраще-
нию решения некоторых функциональных задач, обладающих низким
приоритетом. я1Защита от искажения и потери накопленной информации я0предус-
матривает контроль результатов перед их переписью и в процессе
переписи в зоне долговременного хранения информации, а также за-
щиту этих зон от случайной записи в них информации программами,
не предназначенными для этой операции. я1Защита квазинепрерывных переменных я0состоит в использовании
контроля гладкости изменения этих переменных с течением времени
или в зависимости от другого параметра. Подготовка, статистическая обработка и накопление данных по
проявлениям искажений проводятся автоматически с выдачей периоди-
чески или по запросу сводных данных на индикацию для подготовки
специалистами решений о корректировке программ или восстановлении
аппаратуры. Полезное время функционирования ПС соответствует относитель-
ной длительности решения функциональных задач. Время простоя оп-
ределяется периодом обнаружения и восстановления после отказа.
Время контроля, обнаружения отказовых ситуаций и восстановления
без регистрации отказа может не учитываться в продолжительности
неработоспособного состояния. Таким образом, все время контрольно-восстановительных опера-
ций, не завершающихся регистрируемым отказом, считается я_полезным
я_временемя., так же как время решения основных функциональных задач. Готовность системы включает два слагаемых: вероятность того,
что в момент поступления данных на обработку ПС окажется в рабо-
тоспособном состоянии; и вероятность того, что исходные данные
застанут программы в состоянии контроля и восстановления, однако
эти операции закончатся до использования допустимого резерва вре-
мени. Предполагается, что в ПС реализован дискретный и достоверный
контроль работоспособности и отказы возникают только в рабочем
режиме. Рациональными являются предположения об экспоненциальном
распределением наработки между отказовыми ситуациями и времени
восстановления работоспособности. Один из подходов к оценке рациональных затрат на отладку
состоит в определении оптимальной длительности разработки, при
которой затраты на ее выполнение и затраты на оперативный конт-
роль и восстановление в процессе эксплуатации в сумме минимизиро-
ваны. Эти суммарные затраты обеспечивают одну и ту же интенсив-
ность пропуска необнаруженных искажении, приводящих к отказу при
различной длительности отладки. Заданная вероятность отказа может достигаться повышением
затрат на отладку и увеличением ее длительности или за счет высо-
кой эффективности средств оперативного контроля и восстановления.
Анализ вероятности отказа можно можно проводить по двум критериям: - минимизация затрат, обеспечивающих заданную вероятность
возникновения и обнаружения я_отказовой ситуациия.; - минимизация затрат, обеспечивающих заданную я_наработку на
я_отказя.. я_Длительность отладки я.представляет собой время функционирова-
ния программ, в течение которого проявляются отказовые ситуации и
ошибки. По этой величине может быть определено календарное время
проведения работ по отладке и полные временные затраты на обнару-
жение и устранение ошибок. На совокупном учете перечисленных выше факторов осуществля-
ется я_оптимизация длительности отладки по суммарным затратам на
я_отладку и оперативную помехозащитуя.. Для каждого разрабатываемого ПС целесообразно создавать план
мероприятий и методику, обеспечивающие необходимые показатели на-
дежности. Прежде всего с учетом динамических характеристик и
инерционности объектов управления должны быть определены и сфор-
мулированы основные требования к надежности конкретного ПС: необ-
ходимая наработка на отказ; допустимая длительность восстановле-
ния; коэффициент готовности и т.д. Кроме того необходимо оценить достоверность обрабатываемых
данных и возможную степень влияния их искажений на показатели на-
дежности ПС. На основе этих данных производится распределение ресурсов на
отладку программ и на разработку средств оперативного контроля и
восстановления. Структура ПС и его компонент должна быть потенци-
ально устойчивой к внешним искажениям и позволять оперативно пов-
торять вычисления при при отказовых ситуациях. Для качественной
отладки разрабатываются методика планирования и проведения тести-
рования программных компонент и ПС в целом, методика достигнутого
уровня отлаженности. Для обеспечения надежного функционирования в ПС вводятся:
средства регистрации сбоев и аномалий функционирования; средства
накопления и обработки характеристик отказовых ситуаций; средства
подготовки и реализации решений по оперативному восстановлению
данных, программ и вычислительного процесса. Эти средства объеди-
няются схемой обеспечения надежности ПС, компоненты которой час-
тично размещаются в функциональных программах, а частично предс-
тавляют специальную группу программ контроля и восстановления. Для проверки достигнутых показателей надежности проводятся
испытания ПС при реальных потоках информации, которые создаются
имитаторами или реальными объектами. Интенсивность потоков и уро-
вень искажения исходных данных задаются такими, чтобы проверить
надежностьПС в типовых условиях функционирования, а также в особо
сложных режимах поступления данных из внешней среды. Показатели
надежности, полученные в экстремальных режимах, должны пересчиты-
ваться на средние условия с учетом вероятности возникновения та-
ких ситуаций при реальном функционировании ПС. 16. Проектирование автоматизированных экономических информа-
ционных систем на базе персональных ЭВМ; особенности и технологи-
ческие аспекты проектирования АЭИС, создаваемых на основе ПЭВМ;
обоснование выбора состава автоматизированных функций при созда-
нии и проектировании АЭИС (31.1). Персональные ЭВМ (ПЭВМ) представляют собой особый класс
средств вычислительной техники. Они отличаются высокой надеж-
ностью, дешевизной, компактностью, малым потреблением энергии.
Эти свойства позволяют создавать на их основе автоматизированные
рабочие места (АРМ) широкого назначения. ПЭВМ дает возможность построения информационных систем ново-
го типа, отличающихся, с одной стороны разнообразием средств
отображения информации, с другой - интеграцией этих средств и
обеспечением максимального удобства и простоты работы пользовате-
лей, не обладающих специальной подготовкой. Имея низкую стоимость аппаратной составляющей, ПЭВМ вместе с
тем обладает высокой надежностью работы, необходимость которой
вызвана условиями их ориентации на индивидуальное использование
непрофессионалами в области применения средств вычислительной
техники. Возможность использования ПЭВМ пользователем-неспециа-
листом в области систем обработки данных (куда относятся и АЭИС)
обусловлена прежде всего удобством сравнительно недорого гибкого
и универсального программного обеспечения. Отличительной особенностью ПЭВМ в области программного обес-
печения является то, что при сравнительно с ЭВМ общего назначения
малых изменениях в технологии программирования я_прикладных прог-
я_раммя. существенно увеличиваются масштабы применения я_готовых прог-
я_раммя.. При этом проблема выбора и освоения пакетов программ, сос-
тавляющих операционную обстановку ПЭВМ, решается с помощью стан-
дартных моделей диалога человек-компьютер. В настоящее время соз-
даны так называемые "дружественные" приемы общения разработчика и
пользователя с персональным компьютером, эффективность которых не
вызывает сомнения. я_Особенности проектирования АЭИС, создаваемых на основе пер-
я_сональных ЭВМя.. Наметилась тенденция, заключающаяся в обеспечении
возможности использования ПЭВМ без посредников, иначе, - конечные
пользователи формулируют свои информационные потребности в форма-
лизованном виде, вводят их в ПЭВМ, которая интерпретирует их,
создавая проект машинной обработки данных. Приближение пользова-
теля к ПЭВМ в области проектирования АЭИС прежде всего находит
отражение в том, что последний может участвовать в процессе про-
ектирования не только на первой и последней его стадиях (т.е. на
стадии обследования и внедрения проекта), но и в ходе самого про-
ектирования. Вместе с тем современное состояние прикладного прог-
раммного обеспечения, выступающего в качестве инструментальных
средств проектирования АЭИС, не позволяет полностью передать весь
процесс проектирования в руки конечного пользователя, а лишь спо-
собствует тесному взаимодействию его с проектировщиками АЭИС. При этом выдвигаются определенные "стандартные" требования к
потенциального пользователя АЭИС, являющиеся конечной целью про-
ектирования: удобный ввод проблемно-ориентированной информации;
быстрый доступ к ранее введенной информации; создание личных кар-
тотек, деловых календарей, записных книжек и других средств орг-
техники. На основании всей совокупности требований сложилась кон-
цепция построения и проектирования информационной системы. При построении АЭИС на базе ПЭВМ, оснащенного интегрирован-
ными программными средствами, следует учитывать, что между ПЭВМ и
пользователем нет промежуточного звена (оператора или программис-
та). Следовательно, ПЭВМ должны быть настроены на решение задач
конкретной предметной области и адаптированы к возможностям ко-
нечного пользователя. я_Технологические аспекты проектирования АЭИС, создаваемых на
я_базе ПЭВМя.. Пользователь должен воспринимать информационную систе-
му не как источник дополнительных обязанностей, а только как инс-
трумент, позволяющий ему экономить силы и время. Это утверждение
вызывает целый ряд требований к проектированию и внедрению АЭИС,
построенной на базе ПЭВМ: - пользователь не должен тратить значительное время на добы-
вание информации о существующих современных прикладных програм-
мах, их возможностях и совместимости, а также на их изучение; - прикладные программы должны быть настроены на привычную
технологию работы пользователя и включать в себя меню, поддержи-
вающее эту технологию; - каждый шаг работы пользователя должен сопровождаться подс-
казкой так, чтобы не было необходимости обращаться к документации
прикладной программы; - внедрение должно осуществляться постепенно, так, чтобы
пользователь обучался работе с машиной на простых, и, желательно,
игровых примерах, и это обучение стимулировало его к более серь-
езной работе; - у пользователя не должно возникать чувство дискомфорта в
общении с ПЭВМ. Основным исходным документом, на основе которого создается
АЭИС является общий план деятельности (работы), в котором отража-
ются объекты автоматизации, раскрывается их содержание и ожидае-
мые результаты, указываются ресурсы, даются технико-экономичес-
кие и финансовые показатели. Другой тип документов - это различ-
ная справочная информационная, содержащая детальные сведения о
предмете деятельности. Технология проектирования АЭИС с использованием ПЭВМ должна
включать прежде всего создание модели работы специалиста конкрет-
ной предметной области, которая строится на основе данных обсле-
дования, и анализ возможностей существующего прикладного прог-
раммного обеспечения, комплекс которых может быть использован в
качестве основы информационной системы. Следующим этапом является
настройка данного программного обеспечения на предметную область
конечного пользователя. я_Унификация пользовательского интерфейса проектируемых АЭИС
предполагает максимальное единство средств и способов организации
работы пользователя с различными пакетами программ, входящими в
систему. Он требует единой организации меню и функциональной кла-
виатуры, структуры экрана, выдачи поясняющих сообщений и работы с
объектами обработки - текстами, частями таблицы, фрагментами баз
данных, графиками. Для реализации этого принципа применяются: - унифицированная структура экрана, состоящая из областей
меню, рабочей области, на которой появляются информационные объ-
екты, областей состояния, сообщений и редактирования; - объектный подход к обработке информации, заключающийся в
выборе и выделении некоторого информационного объекта и последую-
щем его преобразовании; информационным объектом может быть строка
меню, фрагмент пакета, диапазон клеток таблицы или базы данных; - типовая структура меню, заключающаяся в разбиении набора
функций на горизонтально расположенное горизонтальное меню и
вспомогательное меню, посредством которых детализируются функции
основного меню; - единая структура функциональной клавиатуры, определяющая
выполнение однотипных функций в разных пакетах программ, одними и
теми же клавишами (перемещение и выделение объектов, отмена за-
данных операций, редактирование, получение поясняющих сообщений; - типовая организация контекстно-чувствительных поясняющих
сообщений, выводимых по требованию пользователя в любой момент
работы системы. Для лучшего "понимания" пользователя реализуется
определенный вид помощи; если пользователь находится в такой ста-
дии работы, что пакету программ невозможно определить, что требу-
ется пояснить, на экран выводится меню помощи, из которого выби-
рается необходимый объект или функция для пояснения. я_Вопросы выбора предметной области использования ПЭВМ при
я_создании АЭИСя.. Исходя из сложившегося опыта применения ПЭВМ в
системах организационного управления, сложились следующие вариан-
ты использования ПЭВМ, характеризующиеся особенностями технологи-
ческого подхода к проектированию информационных систем для реше-
ния экономических задач: 1) автономное использование (изолированные автоматизирован-
ные рабочие места - АРМы); 2) использование ПЭВМ в составе локальных сетей; 3) использования ПЭВМ в качестве интеллектуальных терминалов
больших или средних ЭВМ. Наиболее часто встречающимся и простым является первый вари-
ант. Такой вариант имеет очевидные преимущества: независимость,
самостоятельность конечных пользователей; простота технической
структуры системы обработки данных; отсутствие жестких требований
на совместимость различных технических средств. Однако этот под-
ход имеет и существенные недостатки. Его использование может при-
вести к дублированию информации в разных местах, создать извест-
ные трудности в поддержании целостности, непротиворечивости ин-
формации. Автономное использование ПЭВМ возлагает на самого ко-
нечного пользователя ответственность и обязанности по созданию и
поддержанию информационной базы. При больших объемах обрабатывае-
мой информации это может потребовать больших затрат. Существуют определенные критерии выбора состава автоматизи-
руемых функций информационной системы, которые, если их рассмат-
ривать в приоритетном порядке, сводятся к следующему: - степень влияния реализации обобщенной функции на основные
технико-экономические и финансовые показатели; - трудоемкость реализации внутренних функций (частных функ-
ций) самого структурного звена в ручном и автоматизированном ва-
риантах; - объем хранимой и передаваемой информации, необходимый для
реализации частных функций и определяемый с учетом информационной
емкости документов, показателей, процедур, а также их взаимосвязи
и периода хранения; - трудоемкость автоматизации частных функций. Работы по созданию и, следовательно, проектированию удобных
для пользователей систем основываются на подборе более подходящих
моделей человеко-машинного взаимодействия, учете особенностей оп-
ределенных сфер применения автоматизированных систем. Выбор я_состава автоматизированных функций при создании и про-
я_ектировании АЭИС я.включает следующие этапы: 1 этап - выявление и формулировку обобщенной функции дея-
тельности структурного звена в организационной структуре объекта. 2 этап - выявление перечня основных технико-экономических и
финансовых показателей деятельности объекта, значение которых за-
висят от деятельности структурного звена (либо характеризуют уро-
вень реализации обобщенной функции его деятельности). 3 этап - определение степени улучшения технико-экономических
показателей объекта или его структурного звена в результате авто-
матизации частных функций. 4 этап - декомпозиция обобщенной функции структурного звена
на его частные функции. На этом этапе осуществляется проверка пе-
речня частных функций на полноту и непротиворечивость по отноше-
нию к обобщенной функции. 5 этап - определение трудоемкости выполнения каждой из выяв-
ленных частных функций в ручном исполнении. На основе экспертизы
определяется определяется доля общей трудоемкости звена, необхо-
димая для реализации каждой частной функции. Трудоемкость частных
функций в автоматизированном варианте определяется впоследствии
на основе показателя степени автоматизации функции. 6 этап - выдедение из общего перечня частных функций струк-
турного звена ядра ключевых (желательно взаимосвязанных между со-
бой) функций. Критерием отбора здесь выступает существенность
влияния на изменение уровня реализации обобщенной функции струк-
турного звена на значение выбранных технико-экономических и фи-
нансовых показателей деятельности объекта. 7 этап - декомпозиция каждой ключевой частной функции на
процедуры. Из общего перечня выявленных процедур выделяются для
каждой ключевой функции: базовые процедуры в реализации ключевой
функции; критерием выделения базовых процедур является возмож-
ность влиять на уровень реализации ключевой или обобщенной функ-
ции функции структурного звена; сопутствующие (обеспечивающие)
процедуры, необходимые для реализации базовых процедур. 8 этап - выделение блоков потенциально автоматизируемых про-
цедур; для каждой базовой процедуры строится логический граф ее
реализации посредством сопутствующих процедур и взаимосвязей с
другими базовыми процедурами. 9 этап - определение трудоемкости реализации ключевых функ-
ций в автоматизированном варианте на основе определения доли ав-
томатизируемых процедур. 10 этап - определение объема хранимой и передаваемой информа-
ции по ключевым функциям; определение возможности автоматизации
ядра ключевых функций с учетом информационных возможностей вычис-
лительной техники; проработка вариантов расширения - сужения ядра
ключевых функций для различных вариантов технической реализации
АЭИС. При этом необходимо учитывать: 1) устойчивость процедур, функций и ядра к возможным измене-
ниям организационной и технологической структур, а также хозяйс-
твенного механизма; 2) компактность реализации функций структурного звена; 3) временную последовательность (одновременность) их реали-
зации; 4) трудоемкость автоматизации процедур и функций.
17. Проблемы выбора языка программирования при проектирова-
нии АЭИС на базе ПЭВМ; фреймовый подход к организации объектной
базы. я_Проблемы выбора языка программирования при проектировании
я_АЭИС на базе ПЭВМя.. Когда возникает необходимость создания большой
информационной системы или системы для решения какой-нибудь част-
ной экономической задачи на ПЭВМ, встает вопрос о выборе для этой
цели наиболее подходящего языка программирования. Во многих слу-
чаях такой выбор диктуется очень простыми "земными" факторами -
доступностью того или иного транслятора и умением составлять
программы на данном языке. Если, однако в распоряжении пользова-
теля имеется достаточно большой выбор языков программирования, то
следует учитывать следующие обстоятельства: - назначение разрабатываемой программы - нужна ли она вре-
менно, или будет использоваться постоянно, планируется ли переда-
вать ее другим организациям, будут ли разрабатываться ее новые
версии; - ожидаемый размер программы - можно ли будет создавать как
единое целое или придется разбивать на отдельные взаимодействую-
щие модули, требуется ли минимизировать объем памяти, занимаемой
программой во время работы; - необходимость сопряжения разрабатываемой программы с дру-
гими пакетами или программами, в том числе составленными на дру-
гих языках программирования; - предусматривается ли возможность переноса программы на
другие типы ПЭВМ; - основные типы данных, с которыми придется иметь дело, не-
обходимость поддержки работы с действительными числами, строками,
списками и другими типами структур; - характер и уровень использования аппаратных средств -
дисплея, клавиатуры и др., необходимость в специальном програм-
мировании некоторых функций для работы с внешними устройствами; - возможность и целесообразность использования имеющихся
стандартных библиотек подпрограмм, процедур, функций. С точки зрения этих критериев возможности языков могут весь-
ма сильно различаться, поэтому правильный выбор Если встает задача построения большой прикладной системы, в
которой должно быть несколько взаимодействующих модулей, и при
этом необходима еще экономия памяти и достижение максимально воз-
можного быстродействия программы Стыковка отдельных модулей или программ представляет собой
отдельную проблему, которая может решаться разными способами и, в
частности, может повлиять на выбор инструментального языка (или
языков программирования). я_Объектно-ориентированные прикладные АЭИСя.. Реализация конк-
ретной прикладной автоматизированной системы на ПЭВМ может осу-
ществляться по двум направлениям. Проблемно-ориентированное, наиболее распространенное, пред-
полагает первоочередную разработку отдельных функциональных ком-
понентов, которые затем связываются в единую систему. Возникающие
при этом проблемы выбора внутреннего представления данных и реа-
лизации пользовательского интерфейса решаются, исходя из потреб-
ностей конкретной группы пользователей, для которых создается
система. При таком подходе автоматизированная система наиболее
точно соответствует исходным требованиям и наилучшим образом ис-
пользует ресурсы компьютера. Однако процесс разработки в этом
случае сильно затягивается , а возможности переноса конкретных
компонентов и полученного опыта на системы других классов сильно
ограниченны - новые автоматизированные системы обычно разрабаты-
ваются заново. Объектно-ориентированное направление предполагает создание
ряда унифицированных компонентов, которые в совокупности образуют
как бы обрамление для специальных функциональных подсистем. В
этом случае разработчики могут пользоваться готовыми модулями и
пакетами для компоновки конкретной автоматизированной системы,
дополняя их в случае необходимости специализированными пакетами.
При этом, возможно, утрачивается оптимальность с точки зрения на-
илучшего использования ресурсов ПЭВМ для решения данного класса
задач, зато сроки разработки резко сокращаются. Новые классы ав-
томатизированных систем при таком подходе могут создаваться с су-
щественным использованием прежнего опыта. я_Система управления объектной базой АЭИСя.. Взаимодействие че-
ловека и ПЭВМ при решении прикладной задачи протекает в рамках
сценария, задуманного и реализованного создателем информационной
системы. Система управления объектной базой (СУОБ) обеспечивает
стандартное представление терминальных данных (целых и десятичных
чисел, примитивных графических элементов и структурных объектов,
состоящих из отдельных компонентов (текстов, таблиц, изображений,
составных объектов). СУОБ включает специальный пакет, обеспечивающий работу с
виртуальной памятью; при этом отдельные элементы данных размеща-
ются в общем хранилище и снабжаются уникальными внутренними име-
нами (ключами), по которым к ним осуществляется доступ из функцио-
нальных процессоров и любых прикладных программ. Виртуальная па-
мять реализуется на обычных файлах с прямым доступом. Кроме того,
стандартная файловая система ДОС используется для хранения боль-
ших текстов и некоторых специальных объектов. Для представления информационных моделей может быть примене-
на организация данных, основанная на фреймовом подходе. Унифицированные функциональные процессоры обеспечивают рабо-
ту с типовыми объектами - текстами, таблицами, графиками, рисун-
ками и др. Эти объекты служат носителями содержательной информа-
ции предметной области. Благодаря единому подходу к их реализации
обеспечивается взаимное согласование представлений данных и обмен
между компонентами разных объектов. Функциональные процессоры
снабжаются средствамии доступа к обрабатываемым объектам: - взаимодействие с пользователями осуществляется на основе
унифицированного пользовательского интерфейса; - обращение к функциональным процессорам из прикладных прог-
рамм обеспечивается через процедурный интерфейс. Во многих традиционных прикладных информационных системах
подпрограммы или отдельные операторы, обеспечивающие диалог с
пользователем, перемежаются с содержательной частью программы. В
таком случае внесение изменений в диалог влечет за собой новую
трансляцию соответствующих программ. Это препятствует удобной
настройке системы для конкретных задач и пользователей. я_Фреймовый подход к организации объектной базыя.. Фреймы явля-
ются основой организации объектной базы в рассматриваемом подхо-
де. Ядром такой структуры является ее описатель, в котором содер-
жится: уникальный ключ (системное имя) данного фрейма; внешнее
имя фрейма (комментарий); ссылка на список свойств; ссылка на
список экземпляров; ссылка на список точек зрения; ссылка на спи-
сок ассоциированных с данным фреймом программ. Уникальный ключ формируется при создании фрейма и остается
его постоянным идентификатором на всем протяжении жизни данного
фрейма. Все остальные компоненты фрейма могут изменяться с тече-
нием времени либо под воздействием команд пользователя, либо при
выполнении определенных внутрисистемных функций. Внешнее имя фрейма - это текстовая строка, в частности, одно
слово, которое служит для пояснения роли данного объекта и его
содержимого. При выводе на экран списка фреймов выдаются их внеш-
ние имена, что дает человеку возможность сориентироваться по та-
кому списку в круге основных понятий предметной области. Список свойств задает типы значений в экземплярах фрейма.
Каждое свойство снабжается внешним именем-комментарием и, кроме
того, имеет порядковый номер, по которому к нему может осущест-
вляться доступ с использование процедурного интерфейса. Число
свойств определяет максимальное число элементов данных в экземп-
лярах данного фрейма. Список экземпляров указывает на основные носители содержа-
тельной информации - экземпляры фрейма. Отдельный экземпляр может
содержать набор элементов данных, удовлетворяющих описателям
свойств. Элементом данных в экземпляре может быть значение одного
из следующих типов: число; текстовая строка; вычисляемая формула;
дата; время; ссылка на команду ДОС, в частности, на любую прог-
рамму; ссылка на другой информационный объект или его компоненты. Ссылочные значения играют важную роль, поскольку с их по-
мощью легко организуются сложные взаимосвязи между объектами.
Подчиненные объекты могут быть активными (программами и пакетами
программ) и пассивными (структурами данных). Такая организация
фреймового объекта ставит его в ряд с абстрактным типом данных. Такая организация позволяет имитировать сетевые и иерархи-
ческие модели данных, а при одинаковом числе элементов данных во
всех экземплярах описываемая структура становится идентичной от-
ношению реляционной базы данных. Фрейм с экземплярами представля-
ет собой информационную модель, на основе которой могут имитиро-
ваться другие традиционные модели данных и абстрактные типы. Фреймовый объект, как таковой, является лишь носителем ин-
формации; пользователем он может рассматриваться с разных точек
зрения, т.е. иметь разные виды: базовый табличный и трафаретный. я_Базовый видя. обеспечивает доступ пользователя ко всем компо-
нентам описателя фрейма, к описателям всех свойств и ко всем эк-
земплярам данного фрейма. Это наиболее полный и соответственно
наиболее сложный способ доступа к фреймовым объектам. я_Табличный видя. дает естественное представление группы экземп-
ляров. При этом в конкретной таблице могут могут быть показаны
лишь некоторые избранные свойства фрейма. Разные таблицы, привя-
занные к одному и тому же фреймовому объекту, позволяют просмат-
ривать содержимое экземпляров в разных аспектах. Таблица имеет
внешнее имя, которое становится вариантом имени данного фрейма. В
таблице также задается заголовок; в ней определены столбцы, отоб-
ражающие свойства фрейма, а каждый экземпляр отображается в одной
из строк. Таблицу можно прокручивать по горизонтали, получая дос-
туп к невидимым на экране столбцам, или по вертикали, получая
доступ к новым экземплярам. я_Трафаретный видя. предназначен для создания и просмотра от-
дельных экземпляров и для создания образцов поиска. Трафарет ана-
логичен листу бумаги с надписями и прорезями, через которые видны
определенные свойства экземпляров. Через такие прорези, называе-
мые слотами, можно вводить и просматривать данные. При поиске и подборе подмножества экземпляров трафарет ис-
пользуется для формирования поискового предписания. При этом в
соответствующих слогах указываются ограничения на отдельные
свойства. Результат поиска отображается в таблицу. 18. Особенности разработки прикладных информационных систем
на основе ПЭВМ; структурирование программ на уровне модулей; раз-
дельно компилируемые модули; библиотеки процедур; генерация объ-
ектных модулей и загрузочных файлов; библиотеки объектных моду-
лей; реализация сегментированных программ с перекрытиями (4.2.). При создании прикладного программного обеспечения (ППП) АЭИС
на основе ПЭВМ большая часть программных модулей составляется на
языках высокого уровня (ЯВУ). Имеется несколько вариантов органи-
зации их взаимодействия, основанных на свойствах ЯВУ, и на осо-
бенностях операционных систем. Часто возникает необходимость
программирования машинно-зависимых частей на языке ассемблера или
макроассемблера, в связи с чем встает задача организации взаимо-
действия программ на ЯВУ с программами на ассемблере. При проектировании большой АЭИС с самого начало необходимо
решать несколько принципиальных вопросов, касающихся общей струк-
туры системы и способов взаимодействия отдельных компонентов. В
частности, должны быть определены следующие характеристики: а) состав исходного текста программ, который может представ-
лять собой: единый текст на ЯВУ или ассемблере; отдельные тексто-
вые модули на ЯВУ или ассемблере, которые составляются независимо
и, возможно даже разными исполнителями; б) структура исполняемой программы, которая может представ-
лять собой: единый модуль, полностью загружаемый в оперативную
память при запуске системы; несколько сегментов, загружаемых в
оперативную память по мере необходимости с частичным взаимным пе-
рекрытием (наложением друг на друга); резидентную часть, загружа-
емую в оперативную память в начале сеанса и одну или несколько
нерезидентных частей, загружаемых в оперативную память по мере
необходимости; в) способ хранения данных, с которыми работает система. Ос-
новные варианты хранения: все данные располагаются в одном файле;
данные распределены по нескольким файлам. Различные сочетания указанных характеристик приводят к пост-
роению прикладных систем, отличающихся очень сильно. Варианты а)
влияют на способ и качество разработки. Варианты б) оказывают
критические воздействия на оперативные характеристики системы -
объем требуемой памяти и быстродействие. Варианты в), с одной
стороны, влияют на быстродействие при доступе к данным, с другой
стороны - на характер использования и экономию внешней памяти. я_Структурирование программ на уровне текстовых модулейя.. Самый
простой способ разработки программ не предполагает применения ка-
ких-либо приемов деления их на модули или на сегменты. Для сос-
тавления такой программы обычно используется текстовый редактор
ЪДДДДДДДДДДї ЪДДДДДДДДДДДДДДДї ЪДДДДДДДДДДДДДї общего назначения
Редактор ГДґтекст программыГДґИнтерпретаторі или редактор, вст-
АДДДДВДДДДДЩ АДДДДДДДДДДДДДДДЩ АДДДДДДВДДДДДДЩ роенный в систему. і ЪДДДДДДДДДДДДДДДї і Процесс разработ- АДДДДДДДґ пользователь ГДДДДДДДДЩ ки программы соот- АДДДДДДДДДДДДДДДЩ ветствует общей
схеме, изображенной на рисунке. Простейшая программа на паскале, печатающая на экране слово
"АЭИС" может выглядеть следующим образом:
ЪДДДДДДДДДДДДДДДДДДДї Более сложные программы включают описа-
PROGRAM Test; і ния типов данных, переменных констант. Важ-
BEGIN і нейшими компонентами программ на ЯВУ являю-
WRITELN ('АЭИС');і тся процедуры и функции, которые обеспечи-
END. і вают структуризацию программ на уровне ис-
АДДДДДДДДДДДДДДДДДДДЩ ходных текстов. Так, например, общая струк-
тура программы на паскале может иметь вид:
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї В этом тексте мож-
PROGRAM имя-программы (параметры программы) і но выделить 3 ос-
<описания глобальных объектов программы - і новных компонента:
типов данных, переменных, констант> і - заголовок про-
PROCEDURE P1 (параметры процедуры P1); і граммы - название,
<описание локальных объектов процедуры P1>і список параметров,
BEGIN і описания типов,
<тело процедуры P1> і глобальных пере-
END; і менных, констант;
PROCEDURE P2 (параметры процедуры P2); і - описания про-
<описание локальных объектов процедуры P2>і цедур - их заголо-
BEGIN і вки с описаниями
<тело процедуры P2> і параметров и тела,
END; і состоящие из вы-
............................................і ражений;
BEGIN і - тело програм-
<начало тела программы> і мы - последовате-
...P1 (...);... {обращение к Р1} і льность выражений,
...P2 (...);... {обращение к Р2} і среди которых вст-
<конец тела программы> і речаются обращения
END. і к определенным вы-
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ ше процедурам. Структуризация программы на уровне исходного текста обеспе-
чивается оформлением отдельных частей алгоритмов в виде процедур
и последующему вызову этих процедур в теле программы. Все необхо-
димые связи между формальными и фактическими параметрами процедур
устанавливаются транслятором языка программирования. (В разных
языках способы оформления указанных компонентов различаются)
Рассмотренный подход позволяет создавать программы, тексты кото-
рых представляют собой единое целое и хранятся в отдельных масси-
вах на внешних носителях. Один из приемов деления исходного текста программы на от-
дельные части состоит в использовании я_метода макрогенерациия.. В
текст главной программы вводятся специальные выражения, указываю-
щие компилятору на необходимость включения в нее текста других
модулей. В системе программирования на основе паскаля "включение"
текстового файла M1.PAS осуществляется с помощью выражения вида:
ЪДДДДДДДДДДДДДДДДДДДДї Возможность текстовой подстановки при
{$INCLUDE: 'M1.PAS'}і вводе (редактировании) исходных текстов
АДДДДДДДДДДДДДДДДДДДДЩ программ иметь дело с относительно неболь-
шими фрагментами текста, каждый из которых содержит определенную
группу функций. я_Раздельно компилируемые модулия.. Если составленная программа
велика по объему (содержит от 500 до 100 и более строк), то про-
цесс трансляции может занимать довольно много времени - до нес-
кольких минут, что Неудобно при интенсивной отладке, когда прихо-
дится часто вносить небольшие изменения в исходные тексты и вновь
транслировать программу. Чтобы этого избежать, применяется другой
подход к построению больших программ - составление отдельных мо-
дулей, которые транслируются совершенно независимо друг от друга
и должны связываться лишь на стадии окончательного формирования
исполняемой программы в машинных кодах. Так, в некоторых реализациях языка паскаль можно использо-
вать два типа раздельно компилируемых модулей: MODULE и UNIT. Модуль MODULЕ внешне оформляется почти как главная программа.
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї Его целью является описание
{ДДДДДДДДДДМодуль P1.PASДДДДДДДДДД}і нескольких взаимосвязанных
MODULE P1 і процедур вместе с необходи-
PROCEDURE PP1 (A:INTEGER); [PUBLIC]і мыми типами, переменными и
BEGIN і константами. Тело у модуля
<тело процедуры PP1> і обычно отсутствует.
END; і Описанные в этом моду-
PROCEDURE PP2 (B:REAL); [PUBLIC] і ле процедуры РР1 и РР2 сна-
BEGIN і бжены специальными указате-
<тело процедуры PP2> і лями [PUBLIC], которые сви-
END; і детельствуют об общедоступ-
BEGIN і ности этих процедур для
END. і других программ.
{ДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД}і Чтобы использовать эти
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ процедуры в главной програм-
ме и в других модулях, их необходимо объявить следующим образом:
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї Указатель EXTERNAL
PROCEDURE PP1 (A:INTEGER); EXTERNAL;і свидетельствует, что объя-
PROCEDURE PP2 (B:REAL); EXTERNAL; і вленные таким образом про-
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ цедуры являются внешними
по отношению к тому модулю, который их использует. Однако обраще-
ния к ним в его теле имеют обычный вид, и внешние процедуры не от-
личаются от тех, которые описаны непосредственно в данном модуле. Этот способ применяется не только при модульном программиро-
вании в рамках одного ЯВУ, но также и при составлении программ из
модулей на разных языках или разных функциональных пакетах. Глав-
ная проблема в этом случае состоит в правильной передаче парамет-
ров процедур и функций, посколько в разной программной среде па-
раметры могут обрабатываться по-разному. я_Библиотеки процедуря.. Модуль типа UNIT, который можно назвать
иначе "блоком", описывается с помощью следующих компонентов. Один
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї из них (я1реализация блокая0) со-
{ДДДДРеализация блока P2.PASДДДДД}і держит тела процедур и вспо-
IMPLEMENTATION OF P2; і могательные типы, переменные
PROCEDURE get_key; і и константы. Другой компо-
BEGIN і нент - я1описание я0 я1блока я0 или
<тело процедуры get_key> і я1интерфейся0 - содержит описа-
END і ния типов, переменных и кон-
<описания и тела других процедур>і стант,а также заголовки про-
BEGIN END. і цедур (без их тел), которые
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ предназначены для использо-
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї вания в
{ДДДДДДДДДДДДДДДДДДДДДДP2.INTДДДДДДДДДДДДДДДДДДДДДДД}і других мо-
INTERFACE; і дулях и
UNIT P2; і в главной
(get_key, key_descr,...<имена других процедур>...)і программе.
TYPE key_descr=RECORD scan_code, ascii:byte end; і В интер-
PROCEDURE get_key; і фейс бло-
..... і ка включа-
<заголовки других процедур данного блока> і ется общий
..... і список имен,
END; і указанных
{ДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДД}і объектов,
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ что дела-
ет их "видимыми" из других модулей. Использование объектов модуля типа UNIT в главной программе
требует включения включения его интерфейса перед заголовком прог-
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДї раммы, и упоминания имени блока
{ДДДДГлавная программаДДДД}і сразу после заголовка программы,
{$INCLUDE: 'P2.INT'} і для чего служит выражение вида:
..... і USES <имя блока>;
PROGRAM PP (input, output);і Начальная часть программы
USES P2; і приобретает в результате вид, пре-
..... і дставленный на схеме слева.
{ДДДДДДДДДДДДДДДДДДДДДДДДД}і Здесь текстовое включение интер-
АДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ фейса блока Р2 в программу РР.PAS
осуществляется с помошью рассмотренного выше выражения $INCLUDE. я_Генерация объектных модулей и загрузочных файловя.. В резуль-
тате компиляции отдельных текстовых модулей порождаются я_объектные
я_модулия.. Например, обращение с целью трансляции исходной программы
PP.PAS имеет вид: ЪДДДДДДДДДДї Объектный модуль, который порождается после і PAS1 PP; і
двух проходов трансляции (PAS1 и PAS2), можно счи- і PAS2 і
тать "полуфабрикатом" - куском машинного кода, го- АДДДДДДДДДДЩ
товым к превращению в я_загрузочный файля.. Объектный модуль заносит-
ся в особый файл, которому придается тип OBJ. Для рассматриваемо-
го примера этот процесс можно изобразить следующей условной схе-
мой: PP.PAS ДДД транслятор ДДД PP.OBJ Следующий этап состоит в преобразовании совокупности отдель-
ных объектных модулей в загрузочный файл типа ЕХЕ или СОМ. Этот
процесс называется я_связыванием объектных модулейя. или я_сборкой за-
я_дачия.. Соответствующая схема преобразования: РР.ОВJ ДДД PP.EXE или PP.OBJ ДДД PP.COM Этот этап реализуется специальной системной программой LINK,
которую называют я_редактором связейя. или я_компоновщикомя.. При обраще-
нии к LINK указываются все объектные модули, которые должны объ-
единены в общую программу; указывается также имя файла с резуль-
тирующей программой, имя файла с листингом (необязательный пара-
метр) и имя файла с библиотекой процедур: LINK я_PP+P1+P2я., я_PPя., я_PP.LSTя., я_PASLIB.LIB объектные загрузоч- файл- библиотека модули ный файл листинг процедур Один из способов оформления независимых частей программ сос-
тоит в создании я_библиотек объектных модулейя., которые затем можно
включать в формируемую задачу на стадии сборки. Для формирования
библиотеки объектных модулей служит вспомогательная программа
LIB, которая позволяет создать новую библиотеку или пополнить
старую процедурами, которые извлекаются из оттранслированных за-
ранее объектных модулей или из другой библиотеки. Общий вид обра-
щения к программе LIB: LIB <старая-библиотека> <размер-страницы> <операции> <файл-с-листингом> <новая-библиотека> При обращении к LIB могут указываться имена старой и новой
библиотеки. Размер страницы (=16, 32 ... 512) задает величину бу-
фера для обмена; это необязательный параметр. Главные действия
задаютсяя1 операциямия0. Операция может иметь следующие разновидности
(mm - имя модуля): + mm {добавление модуля в библиотеку}, - mm {удаление модуля из библиотеки}, * mm {извлечение модуля из библиотеки}, -+ mm {замена модуля в библиотеке}, -* mm {извлечение модуля с удалением}, Пример обращения к LIB: LIB OLDLIB+P2, ,NEWLIB Такое обращение вызывает создание новой библиотеки NEWLIB из
старой OLDLIB c добавлением отдельно оттранслированного модуля
Р2. После того, как библиотека создана, достаточно упомянуть ее
имя при связывании объектных модулей в единую программу. Обращение к библиотечным процедурам в главной программе или
в другом модуле требует их упоминания в начале программы с указа-
телем EXTERNAL, - также как и в случае использования модулей типа
MODULE. При этом необходимо помнить о согласовании типов парамет-
ров библиотечных процедур и функций. Каждая система программиро-
вания имеет собственную библиотеку стандартных процедур/функций. Процесс трансляции складывается из стадий: формирование тек-
стовых модулей (с использованием текстовой подстановки); синтакси-
ческий анализ и выдача ошибок, найденных транслятором в тексте
программы; генерация объектных модулей в машинных кодах, оптими-
зация; сборка из объектных модулей исполняемого кода программы. Эти приемы позволяют при составлении исходных текстов прог-
рамм иметь дело с несколькими автономными компонентами, которые
собираются вместе в начале процесса трансляции (текстовое включе-
ние), или при сборке исполняемых программ (использование раздель-
но компилируемых модулей и библиотек процедур). Благодаря такому
методу программы становятся удобными для анализа и модификации.
Кроме того, появляется возможность нескольким программистам
участвовать в разработке одной системы; каждый из них может зани-
маться своими модулями, при условии, что заранее оговорены "сог-
лашения о связях", включающие имена и способы обращения обращения
к процедурам, входящим в разные модули. Наконец, раздельная ком-
пиляция позволяет собирать программы из модулей, составленных на
разных языках программирования, при условии, что согласованы спо-
собы передачи и обработки параметров процедур и функций. я_Реализация сегментированных программ с перекрытиями.я. Методы
структурирования обеспечивают независимую разработку отдельных
частей прикладной системы; однако получаемый в результате испол-
няемый программный код представляет собой единый файл, который
при вызове программы должен полностью разместиться в оперативной
памяти. Это далеко не всегда устраивает разработчиков системы.
Необходимы способы деления программ на такие части (я1сегментыя0),
которые могли бы постоянно находиться во внешней памяти и загру-
жаться в оперативную память лишь по мере необходимости. В развитой системе программирования, базирующейся на ЯВУ ти-
па паскаль, распространенным приемом такого деления программ на
части основан на созданиия1 перекрывающихся (оверлейных) сегментовя0,
при котором программа составляется из отдельных кусков, (во время
работы они могут по мере необходимости загружаться в оперативную
память и частично накладываться друг на друга. Сегменты хранятся во внешней памяти (на диске) и лишь один
из них - корневой - находится постоянно в оперативной памяти.
Когда в корневом сегменте происходит обращение к процедуре, тело
которой находится в одном из оверлейных сегментов, отсутствую-
щих в данный момент в оперативной памяти, происходит его загрузка
с внешнего носителя в ОЗУ. При этом все связи между частями кор-
невого сегмента и только что загруженным сегментом начинают выг-
лядеть так, как если бы они составляли с самого начала единую
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДї программу. Точно так же происходит
PROGRAM PP (input,output);і по мере необходимости загрузка дру-
....... і гих сегментов из внешней памяти.
OVERLAY PROCEDURE P1; і Пример объявления оверлейных
BEGIN і процедур, тела которых после транс-
<тело процедуры P1> і ляции попадают в соответствующие
END; і оверлейные файлы, приведен на схеме.
OVERLAY PROCEDURE P2; і Трансляция такой программы
BEGIN і приведет к созданию трех перекрыва-
<тело процедуры P2> і ющихся сегментов:
END; і РР.СОМ РР.000 РР.001
PROCEDURE P3; і Первый из них - РР.СОМ - соот-
BEGIN і ветствует главной программе, два
<тело процедуры P3> і других сегмента - оверлейные. При
END; і этом процедуры Р1 и Р2 попадут в
OVERLAY PROCEDURE P4; і сегмент РР.000, поскольку в исход-
BEGIN і ном тексте их описания следуют од-
<тело процедуры P4> і но за другим. Процедура Р4 окажется
END; і во втором оверлейном сегменте - РР.
........ і 001. Такое разделение обусловлено
BEGIN і тем, что описание Р4 отделено от
<P1> і описаний двух первых процедур внут-
END. і ренней (не оверлейной) процедурой
АДДДДДДДДДДДДДДДДДДДДДДДДДДЩ Р3. Получившаяся структура програм-
мы может быть отображена схемой, представленной на на рисунке: Корневой сегмент РР.СОМ Оверлейный сегмент РР.000 ЪДДДДДДДДДДДДДДДДДДДДДДї ЪДДДДДДДДДДДДДДДДДДДДДДДї і код программы і ЪДДґ код процедуры Р1 і ГДДДДДДДДДДДДДДДДДДДДДДґ і ГДДДДДДДДДДДДДДДДДДДДДДДґ і і ГДДґ код процедуры Р2 і іобласть для оверлейныхГДДДЩ АДДДДДДДДДДДДДДДДДДДДДДДЩ ісегментов ГДДДї і і і Оверлейный сегмент РР.001 ГДДДДДДДДДДДДДДДДДДДДДДґ і ЪДДДДДДДДДДДДДДДДДДДДДДДї і код программы і АДДґ код процедуры Р4 і АДДДДДДДДДДДДДДДДДДДДДДЩ АДДДДДДДДДДДДДДДДДДДДДДДЩ 19. Организация взаимодействия программ АЭИС на основе ПЭВМ:
через прерывания ДОС; на языке ассемблера; особенности ассемблер-
ных процедур; резидентные программы; связывание программ через
потоки ввода/вывода (5.2.). Часто нужно организовать взаимодействие программ, которые
составлены независимо и на разных языках программирования. В этом
случае для взаимного вызова программ можно воспользоваться я_преры-
я_ваниями ДОСя.. В ДОС имеется специальное прерывание с десятичным
номером 33 (шестнадцатиричный номер 21 Н), через которое любая
прикладная программа может иметь доступ к внутренним функциям
операционной системы. В их число входит несколько функций, с по-
мощью которых может быть организован взаимный вызов программ. Функция 31 Н (символ Н означает, что число является шестнад-
цатиричным) останавливает данную программу и оставляет ее в опе-
ративной памяти резидентной, что дает возможность позднее вновь
обратиться к ней через соответствующую я1точку входая0. Функция 4В Н обеспечивает вызов (загрузку с диска и переход
на исполнение) другой программы. Когда вызванная программа закон-
чится, управление автоматически передается вызывавшей программе.
Имеется вариант этой функции, когда файл только загружается с
диска, но не исполняется; это используется для загрузки перекры-
вающихся сегментов программ или загрузки данных. Функция 4С Н оканчивает работающую программу с засылкой в
системный регистр ALя1 кода возвратая0. Этот код может быть взят и
проанализирован вызвавшей программой, для чего используется функ-
ция 4D. Функция 4D позволяет выяснить, по какой причине окончи-
лась вызванная программа. Причины могут быть следующие: нормаль-
ное окончание; окончание в результате нажатия клавиш Ctrl + Bre-
ak; окончание в результате фатальной ошибки внешнего устройства;
окончание в результате применения функции 31. Функции 48 Н и 49 Н позволяют соответственно запросить у ДОС
оперативную память для работы программы и освободить ее. Функция
4А Н позволяет изменить (уменьшить или увеличить) выделенную па-
мять. Указанные функции дают возможность прикладной программе Большинство развитых систем программирования на основе ЯВУ
обеспечивает обращение к прерываниям ДОС через специальные проце-
дуры. При этом в регистры микропроцессора засылаются необходимые
параметры. Например, в TurboPascal обращение к прерыванию ДОС
осуществляется процедурой: ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї
Здесь параметр InterruptNo: INTE- іINTR (InterruptNo, Registers)і
GER - целое десятичное число, АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ
указывающее номер прерывания. Параметр Registers - это список ба-
зовых регистров микропроцессора:
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї
Registers = RECORD і
AX, BX, CX, DX, BP, SI, DI, DS, ES, Flags: INTEGER;і
END і
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ
При обращении к прерыванию ДОС необходимо сначала занести в ре-
гистры нужные значения, а после завершения прерывания из них мож-
но извлечь результаты работы. Каждый из двухбайтовых регистров состоит двух однобайтовых
(полу)регистров. Например, двухбайтовый регистр АХ состоит из
двух однобайтовых - АН и AL. Однобайтовые регистры используются
для передачи информации в ДОС. Так, по принятому в ДОС соглашению
регистр АН служит для задания номера функции, вызываемой через
любое прерывание. Если, например, в прикладной программе применяется прерыва-
ние 21 Н и через него вызывается функция 4В Н (загрузка и запуск
другой программы, то регистры заполняются следующим образом: АН = 4В - номер вызываемой функции; AL - признак загрузки программы с исполнением (AL = 0) или
без исполнения (AL = 1); DS : DX - два указанных регистра содержат "длинный" адрес
строки с расширенным именем файла; ES : BX - два этих регистра содержат длинный адрес управляю-
щего блока запускаемой программы, который должен быть оформлен
соответствующим образом. Чтобы пользоваться указанным методом для организации взаимо-
действия программ, от программиста требуется определенная профес-
сиональная подготовка, в частности, знание архитектуры ПЭВМ и
ДОС, умение работать с значениями регистров и др. Обладание этими приемами открывает доступ к мощным средствам
управления программами. Использование разных языков программиро-
вания в этом случае не будет препятствием для для сочетания раз-
личных программ в рамках одной прикладной системы. я_Взаимодействие с программами на языке ассемблера.я. При созда-
нии сложных прикладных систем возникает необходимость в использо-
вании машинно-ориентированных программ на языке ассемблера. Более
того, с целью повышения быстродействия или сокращения требуемых
объемов памяти на ассемблере иногда составляются значительные
фрагменты программ. В этих случаях возникает задача организации взаимодействия
программ на ЯВУ с ассемблерными программами. Ассекмблерные прог-
раммы могут объединяться с другими программами на уровне объект-
ных модулей - с помощью компоновщика LINK. Главная проблема сос-
тоит во взаимной передаче параметров между такими программами. Предположим, имеется ассемблерная процедура для установки
положения курсора в дисплейном окне, которая должна быть доступна
из программ на паскале. Описание соответствующей процедуры в пас-
каль-программе ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї
может иметь іPROCEDURE CURPOS (LINE : INTEGER; POS; INTEGER);і
вид: і EXTERNAL; і Соответс- АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ
твенно обращение к этой процедуре в паскаль- ЪДДДДДДДДДДДДДДДДДї
программе может иметь вид: і CURPOS (L, P); і
Вызываемая программа на ассемблере имеет АДДДДДДДДДДДДДДДДДЩ
следующий вид:
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї
WINDOW SEGMENT 'CODE' ;начало сегмента с именем WINDOW і
PUBlIC CURPOS ;объявление "общедоступной" процедурыі
;CURPOS і
CURPOS PROC FAR ;обеспечение "дальнего" вызова і
;процедуры і
PUSH BP ;сохранение старого указателя на і
;"фрейм" і
MOV BP, SP ;установка нового положения "фрейма" і
PUSH АХ ;сохранение старых значений регистрові
PUSH ВХ ;АХ и ВХ і
MOV BX, [BP+6] ;перенос в регистр ВХ 2-го параметра і
MOV AX, [BP+8] ;перенос в регистр АХ 1-го параметра і
..... і
(выполнение необходимых действий с использованием і
параметров, сохраненных в регистрах АХ и ВХ) і
..... і
POP ВХ ;восстановление регистров ВХ і
POP АХ ;и АХ і
POP ВР ;восстановление старого указателя і
;на стек і
RET 8 ;возврат из процедуры со сдвигом і
;указателя стека на 8 байт назад і
CURPOS ENDP ;конец тела процедуры і
WINDOW END ;конец сегмента WINDOW і
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ В приведенном примере можно отметить несколько характерных
деталей. Необходимо пояснить, что передача информации между вызы-
вающей программой и данной процедурой осуществляется черезя1 стек
- последовательность машинных слов, в которую данные "заталкива-
ются оператором PUSH и "выталкиваются" оператором POP. В стек ав-
томатически заносятся такжея1 адрес возвратая0 из процедуры. На теку-
щую ячейку стека указывается содержание регистра SP. В регистре
ВР находится указатель ная1 фрейм,я0 т.е. на ту часть стека, в кото-
рой хранятся данные, относящиеся к вызванной процедуре. я_Особенности ассемблерных процедуря.. В начале процедуры проис-
ходит сохранение в стеке старого значения регистра ВР, а также
регистров АХ и ВХ, которые далее понадобятся для работы. Затем
происходит важная операция - из стека командой MOV извлекаются
значения двух параметров (заданных в обращении к паскаль-процеду-
ре CURPOS как значения переменных L и Р). Эти значения заносятся
соответственно в регистры АХ и ВХ и используются затем для выпол-
нения основных действий - установки положения курсора в дисплей-
ном окне. Положения параметров в стеке фиксированы относительно
начала фрейма, заданного значением указателя ВР. Первые 4 байта
заняты адресом возврата и старым значением SP, еще 2 байта - ре-
гистром счетчика команд, а параметры занимают по 2 следующих бай-
та и поэтому адресуются конструкциями вида [BP + 6] и [BP + 8].
Следует иметь в виду, что при обращении к данной процедуре из
паскаля стек заполняется от старших адресов к младшим, поэтому
первый параметр находится дальше всего от позиции, на которую
указывает регистр ВР. Если бы параметров было 4, то они бы адресовались с помощью
следующих выражений: [BP + 6] - адрес 4-го двухбайтового параметра, [BP + 8] - адрес 3-го двухбайтового параметра, [BP + 10] - адрес 2-го двухбайтового параметра, [BP + 12] - адрес 1-го двухбайтового параметра. Важным моментом является то, что в данном моменте процедура
CURPOS не меняет значений указанных параметров. Это позволяет пе-
редать их из паскаль-программыя1 по значениюя0, т.е. скопировать в
стек. Если же предполагается изменение параметров в ассемблерной
процедуре, то их нужно передаватья1 по ссылкея0. Для этого описание
процедуры CURPOS в паскаль-программе должно было бы содержать
описания параметров с указателем VAR или VARS, т.е. иметь, напри-
мер следующий вид:
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї В этом случае и извлече-
PROCEDURE CURPOS (VAR LINE : INTEGER;і ние параметров в ассемб-
VAR POS : INTEGER); EXTERNAL; і лерной процедуре должно
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ быть оформлено по-друго-
му. Сначала нужно извлечь из стека на параметр (его адрес), а за-
тем уже взять по этому адресу значение ячейки. я_Резидентные программыя.. Часто бывает необходимо, чтобы слу-
жебная программа сработала и осталась в памяти для того, чтобы
могли позднее обращаться и другие программы. Такую программу на-
зываютя1 резидентнойя0, в отличие от обычных программ, которые по
окончании работы освобождают занятую память. ДОС-функция 31 Н осуществляет остановку программы и оставля-
ет ее резидентной в памяти. К этой функции можно обращаться не-
посредственно из программы на ЯВУ, если в нем обеспечивается дос-
туп к прерываниям ДОС. Можно выполнить те же действия, используя
соответствующую подпрограмму на ассемблере. Фрагмент программы на ассемблере, предназначенной для реали-
зации указанной операции, имеет следующий вид:
ЪДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДї
PUSH ES ;запоминание начала программы в стеке і
.... ; і
POP АХ ;выталкивание адреса начала і
MOV DX, SEG ZZ ;занесение адреса конца программы ZZ ві
;регистр DX і
SUB DX, AX ;вычисление длины программы і
INC DX ;увеличение длины на 1 і
MOV АН, 31Н ;задание в регистре АН номера функции і
;31 Н (остановить задачу и сделать ее і
;резидентной) і
INT 21Н ;обращение к прерыванию 21 Н і
ZZ SEGMENT 'ZZ' ;конец программы ZZ і
ZZ ENDS і
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ Такая подпрограмма может быть соединена с любой другой прог-
раммой на ЯВУ и использована для создания резидентной копии зада-
чи. я_Связывание программ через потоки ввода выводая.. Существует
способ организации взаимодействия программ, основанный на стан-
дартном сервисе, предоставляемом ДОС. В ДОС имеется понятие я1стан-
я1дартного входногоя0 и я1стандартного выходногоя0 устройства. По умолча-
нию эти устройства соответствуют клавиатуре и дисплею. Имеется
возможность переопределять стандартные устройства (или потоки)
ввода и вывода. Вместо клавиатуры и дисплея в этой роли могут вы-
ступать: 1) различные внешние устройства (принтер или коммуника-
ционный канал), 2) любые дисковые файлы, 3) любые программы, ра-
ботающие со стандартным входом и выходом. В программе на ЯВУ стандартное входное и стандартное выход-
ное устройства доступны через обычные операторы ввода/вывода (в
паскале - READ и WRITE) Известно, что такие операторы позволяют
обмениваться с клавиатурой и дисплеем, не задумываясь о том, что
здесь кроются более широкие возможности. В командной строке, обращенной к ДОС и предусматривающей за-
пуск какой-либо программы, можно указать, откуда должен поступать
в программу стандартный входной поток и куда должен направляться
стандартный выходной поток. Благодаря этой возможности можно, не
меняя программ, подключать к ним различные внешние устройства и
файлы в качестве источников и приемников информации, а также ор-
ганизовывать взаимную передачу информации между отдельными прог-
раммами. Если имя программы РР, то изменить ее входной и выходной
потоки можно командой следующего вида: ЪДДДДДДДДДДДДДДДї
Здесь символ "from" соответствует стандартному і PP <from> to і
входному потоку, а символ "to" - стандартному АДДДДДДДДДДДДДДДЩ
выходному потоку. Вместо символов from и to могут фигурировать имена файлов
или зарезервированные имена внешних устройств (CON:, PRN:, LPT:1,
LPT2:, COM:. COM1:, COM2:, AUX:). следует помнить, что одни внеш-
ние устройства работают только выходе (принтер), другие только на
входе (диджитайзер), но есть и такие устройства, которые способны
передавать информацию в обоих направлениях (модемы). Если источником или приемником информации для данной прог-
раммы является другая программа, то используется иное обозначе-
ние. Пример такого обозначения для трех взаимосвязанных программ:
ЪДДДДДДДДДДДДДДДї В данном примере стандартный выходной поток
РР1 і PP2 і PP3і программы РР1 связывается со стандартным вход-
АДДДДДДДДДДДДДДДЩ ным потоком РР2, а ее стандартный выходной по-
ток, в свою очередь, поступает на стандартный вход программы РР3. Для обозначения таких цепочечных связей между программами
используют термин "канал" (англ. pipe). В ДОС такой канал реали-
зуется с помощью временного файла, который операционная система
сама создает в корневом каталоге и уничтожает после окончания ра-
боты программ. В операционной системе Юникс этот же самый меха-
низм реализуется при помощи внутренних файлов, благодаря чему об-
мен информацией между программами происходит гораздо быстрее. Программа, которая принимает данные со стандартного входа и
передает их (после обработки) на стандартный выход называется
я1фильтромя0. К фильтрам относятся некоторые системные утилиты ДОС:
SORT, MORE. Программа-фильтр "пропускает" через себя соответству-
ющую информацию, осуществляя ее переработку. Так, фильтр SORT
обеспечивает сортировку пропускаемых через него текстовых данных;
MORE пропускает текст порциями по 24 строки с остановками (ис-
пользуется при выводе текстов файлов на экран). Можно составлять
собственные программы-фильтры, которые будут осуществлять необхо-
димую переработку последовательных потоков данных. Это может по-
надобиться, например, при организации связи ПЭВМ с большой ЭВМ,
при необходимости перекодировки текстов и при других операциях. Описанный способ взаимодействия программ имеет недостатки: - передача информации между программами осуществляется толь-
ко посредством последовательного потока, а не с помощью парамет-
ров, как это имеет место при процедурном взаимодействии; - у программ занимаются стандартные каналы ввода-вывода; - обмен происходит сравнительно медленно, поскольку реализу-
ется через обычную файловую систему. 20. Автономная отладка и тестирование АЭИС; общие задачи от-
ладки; содержание тестирования; систематизация тестов для отлад-
ки; используемые методы отладки; этапы отладки; отладка программ-
ных модулей; тестирование обработки данных; планирование отладки;
системы автоматизации отладки (27.1). Под отладкой понимается процесс, позволяющий получить нор-
мально функционирующую систему, с требуемыми характеристиками в
заданной области входных данных (информационного пространства). В
результате отладки система должна соответствовать совокупности
правил и заданных показателей качества, принимаемых за эталонные.
Процесс отладки включает: - создание совокупности тестовых (эталонных) значений и пра-
вил, которым должна соответствовать создаваемая программа по вы-
полняемым функциям, структуре, правилам описания, значениям ис-
ходных и соответствующих им результирующих данных; - статическую проверку тестов разработанных программ и дан-
ных на на выполнение всех заданных правил построения без исполне-
ния объектного кода; - тестирование программы с ее исполнением в объектном коде и
с разными уровнями детализации: детерминированное, стохастическое
и тестирование в реальном времени; - диагностику и локализацию причин отклонения результатов
тестирования от заданных эталонных значений или правил; - изменение программы с целью исключения причин отклонения
результатов от эталонных. я_Содержание тестирования систем (программ)я.. Основным методом
обнаружения ошибок при отладке является их я1тестированиея0. Эффек-
тивность тестирования - важнейший фактор, определяющий стоимость
и длительность разработки сложных АЭИС с заданным качеством. Зат-
раты на тестирование для обнаружения ошибок составляют 30-40% об-
щих затрат на разработку и в значительной степени определяют ка-
чество созданной АЭИС. Высокая доля затрат на тестирование приво-
дит к необходимости создания методов и средств, позволяющих дос-
тигать нужного качества систем при реальных ограничениях на дли-
тельность тестирования и связанные с этим затраты. Программы как объекты тестирования имеют ряд особенностей,
которые отличают процесс тестирования от традиционного, применяе-
мого для проверки аппаратуры и других технических изделий. При
этом отсутствует полностью определенный и точный эталон для всех
тестовых наборов. В связи с этим для тестирования в качестве эта-
лонов используется ряд косвенных данных, которые не полностью от-
ражают функции и характеристики отлаживаемых программ. На практике невозможно создать единственный универсальный
метод тестирования; поэтому обычно применяют ряд значительно раз-
личающихся я_категорий тестовя.. Каждая категория тестов отличается
целевыми задачами, проверяемыми компонентами программ и методами
оценки результатов. Существуют следующиея1 категории тестовя0: - я2тестирование для обнаружения ошибок я0- выявление отклонений
результатов функционирования реальной системы от заданных эталон-
ных значений; задача состоит в обнаружении максимального числа
ошибок, в качестве которых принимается отклонение от эталонов; - я2тестирование для диагностики и локализации ошибокя0, состоя-
щего в установлении места искажения программы (данных), явившего-
ся причиной отклонения полученных результатов от эталонных; - я2контрольное тестированиея0, состоящщего в подтверждении пра-
вильности выполненной корректировки разрабатываемой системы. Каждая из категорий тестов отличается целевыми задачами,
проверяемыми компонентами и методами оценки результатов. Совмест-
ное и систематическое применение различных методов тестирования
позволяет достигать высокого качества функционирования АЭИС. я_Систематизация тестов для отладки систем (программ).я. Для от-
ладки применяются методы, предусматривающие упорядочивание и сис-
тематизацию тестов по различным стратегиям и параметрам, и методы
неупорядоченного тестирования ("черного ящика"). При последнем
исходные данные, имитирующие внешнюю среду случайным образом, ге-
нерируются во всем диапазоне возможного изменения параметров.
Стремление к рациональному использованию ограниченных ресурсов
системы приводит к необходимости я1систематизации процесса тестиро-
я1ванияя0. Методы упорядоченного тестирования основываются на выделе-
нии факторов и параметров, позволяющих эффективно распределять
ресурсы тестирования с учетом их влияния на качество разрабатыва-
емой программы. я_Статическое тестированиея. является наиболее формализованным и
автоматизируемым методом проверки корректности системы (програм-
мы). В качестве эталонов применяются правила структурного постро-
ения аппаратных и программных модулей и обработки данных, конкре-
тизированные для проекта информационной системы в целом. Кроме
того, могут также использоваться некоторые частные правила обра-
ботки данных, зафиксированные в спецификациях на отдельные компо-
ненты системы. Операторы и операнды текста программ анализируются
в символьном виде, вследствие чего этот метод называют также я1сим-
я1волическим тестированиемя0. Развитие и углубление символического
тестирования может доводиться до уровня я1формальной верификации
я1программ я0на соответствие ее текста детальной спецификации, опре-
деляющей связи между входными и выходными данными программы. Особенностью методов я_динамического тестированияя. является
проверка исполнения тестов программами системы в объектном коде.
Наиболее трудоемким из них является метод я1детерминированного тес-
я1тированияя0. При этом контролируются каждая комбинация исходных
эталонных данных и соответствующая ей комбинация результатов
функционирования программы. Это позволяет выявить отклонение ре-
зультатов от эталона с фиксированием конкретных значений исходных
и результирующих данных, при которых это отклонение обнаружено. я_Используемые методы отладки систем (программ)я.. В сложных
системах невозможно перебрать и задействовать все комбинации ис-
ходных данных и проконтролировать результаты функционирования
создаваемой программы на каждой из них. В таких случаях применя-
ется я1стохастическое тестированиея0, при котором исходные тестовые
данные задаются множеством случайных величин. Стохастическое тес-
тирование применяется в для обнаружения ошибок, а для диагностики
и локализации ошибок переходят к детерминированному тестированию. Последующее расширение области изменения исходных данных
становится возможным при применении я1тестирование в реальном вре-
я1мения0. В процессе такого тестирования проверяются исполнение сис-
тем (программ) и обработка исходных данных с учетом времени их
поступления, длительности и приоритетности обработки, динамики
использования памяти и взаимодействия с другими программами. Отладку АЭИС можно осуществлять при двух стратегиях наращи-
вания числа компонент, подлежащих проверке. При систематическом я_восходящем тестированиия. вначале проверя-
ются модули нижних иерархических уровней, к которым постепенно
подключаются вызывающие их модули. При этом обеспечивается рабо-
тоспособность вызываемых компонент и функции группы программного
обеспечения системы проверяются при их естественном исполнении.
Все участвующие в тестировании модули нижних иерархических уров-
ней тестируются детально и независимо. Это обеспечивает их высо-
кую корректность при подключении к вызывающим модулям. При я_нисходящем тестированиия. проверки начинаются с программ-
ных модулей управления и организации вычислительного процесса.
Внвчале тестируются управляющие программы, а также программы ре-
шения функциональных задач, размещенные на высших иерархических
уровнях. К ним постепенно подключаются для тестирования программы
последующих, более низких иерархических уровней. Преимуществом
такого метода является возможность сохранения и развития наборов
тестовых исходных данных по мере подключения программ нижнего
уровня. На практике оба метода используются совместно с учетом слож-
ности тестируемых групп программ, а также планов проектирования
АЭИС. Модули и группы программ многократного использования преи-
мущественно тестируются по восходящему методу. Управляющие и уни-
кальные модули (с малым числом вызываемых программ) при небольшом
числе иерархических уровней целесообразно тестировать по нисходя-
щему методу. я_Этапы отладки систем (программ)я.. Объекты отладки и тестиро-
вания применяются в соответствии с поэтапным развитием программ
от уровня алгоритмов до уровня завершенного эксплуатируемого и
сопровождаемого программного средства. При я2тестировании спецификаций требований я0основная цель сос-
тоит в проверке полноты и взаимного соответствия функций, предпи-
сываемых программным компонентам разных иерархических уровней.
Задачи тестирования включают проверку взаимно однозначного соот-
ветствия информации на входах и выходах взаимодействующих прог-
рамм. я2Тестирование программных модулей я0- наиболее формализованный
и автоматизированный процесс тестирования. Основная задача состо-
ит в проверке обработки программными модулями поступающей инфор-
мации и корректности получающихся на на выходе данных в соответс-
твии с функциями, представленными в спецификациях. я2Тестирование функциональных групп программ я0предназначено для
проверки корректности решения крупных автономных функциональных
задач АЭИС. Проверяется правильность управляющих и информационных
связей между модулями, а также корректность вычислений в процессе
обработки информации. я2Тестирование комплексов программ при отладке я0- сложный про-
цесс, в котором завершается проверка корректности функционирова-
ния программ при правильных исходных данных и осуществляются ос-
новные проверки при искажениях на входе. Проверяется надежность
функционирования всей АЭИС в реальных условиях и эффективность
средств программной защиты и восстановления. Определяются кор-
ректность использования программами ресурсов ВС и функционирова-
ние программ в критических условиях. я2Тестирование комплекса программ при испытаниях я0предназначено
в основном для проверки соответствия ТЗ и для оценки пригодности
АЭИС к регулярной эксплуатации и сопровождению. Для этого прове-
ряется полнота и точность технической документации и качество
функционирования программ по всем требованиям ТЗ. я2Тестирование системы при сопрвождении я0осуществляется с ис-
пользованием практически всех перечисленных выше категорий тес-
тов, характерных для разработки и испытаний АЭИС. Сопровождение
является частичным повторением процесса создания программ или его
отдельных этапов. Выбор используемых тестов варьируется в широких
пределах в зависимости от содержания вносимых изменений. При соп-
ровождении активно применяются тесты, связанные с обеспечение
сохранности данных на магнитных носителях. Систематизация тестов позволяет последовательно акцентиро-
вать внимание на обнаружении ошибок определенных классов. Полные
затраты на все тесты оправданы и необходимы, когда система выпол-
няет особенно ответственные функции и его недостаточное качество
грозит большим ущербом. я_Отладка программных модулейя. включает в себя: я2Ручное тестирование я0проводится по листингам после трансляции
и устранения автоматически обнаруживаемых ошибок с применением
методов: ручное тестирование за рабочим столом индивидуально соз-
дателем данной программы; сквозной просмотр текста и тестирование
программы группой специалистов; инспекция группой специалистов
текстов программы на логику ее функционирования с позиции типовых
ошибок. В качестве эталона при проверках используется специфика-
ция требований. Вычисления проверяются путем сравнения с резуль-
татами независимых расчетов по исходным формулам. я2Символическое тестированиея0, в процессе которого анализируют-
ся не числа, а формулы программ, записанных в символическом виде.
Они связывают наборы входных переменных системы и выходных пере-
менных, участвующих в исполнении программы по определенному марш-
руту. Основная цель состоит в установлении соответствия между об-
ластями определения наборов данных (входных и выходных) и маршру-
тами их обработки в программе. я_Тестирование структуры программных модулейя.. Тестирование
структуры программ или потоков управления может проводиться вруч-
ную на символическом уровне и при детерминированном исполнении
программы в процессе обработки реальных тестовых данных. Детерми-
нированное тестирование структуры имеет целью проверку коррект-
ности маршрутов исполнения программ, обнаружение в основном логи-
ческих ошибок формирования маршрутов и получение информации о
полной совокупности реальных маршрутов исполнения в программе.
Маршруты позволяют упорядоченно контролировать достигнутую сте-
пень проверки программ и предохраняют от случайного пропуска от-
дельных нетестировавшихся маршрутов. При планировании тестирова-
ния структуры программы возникают две задачи: формирование крите-
риев выделения маршрутов для тестирования и выбор стратегий упо-
рядочения выделенных маршрутов. я_Тестирование обработки данныхя.. Функционирование системы
рассматривается как обработка потока данных, передаваемых от вхо-
да в систему к ее выходу. Задача анализа потока состоит в уста-
новлении правильности их обработки и в выявлении ошибок в тести-
руемой программе. Эта задача может решаться я1статистическия0 без ис-
полнения программы (по ее тексту) и я1динамически я0путем использова-
ния программы в объектном коде при конкретных исходных данных.
Последствия ошибок в программе могут проявляться как малые изме-
нения переменных в процессе вычислений и как полное искажение или
отсутствие на выходе требующихся величин. Целесообразно выделить
следующие методы тестирования и последовательность их применения: - тестирование при значениях данных, определяющих ветвления
в программе и маршруты исполнения программы; - тестирование записи и считывание переменных при вычислении
и полноты состава выходных данных на всех маршрутах исполнения
программы; - тестирование точности результатов вычислений и корректнос-
ти обработки каждой переменной; - тестирование на полное соответствие состава и значений вы-
ходных данных программной спецификации. я_Планирование отладки программных модулейя.. Автоматизированно
можно производить подготовку исходных данных: о циклах в програм-
ме; о маршрутах исполнения программы и предикатах, определяющих
маршруты исполнения программы и границы изменения областей изме-
нения переменных. Выделение циклов и маршрутов в них позволяет
преобразовывать программу к антициклическому виду. При этом циклы
заменяются их антициклическими эквивалентами с фиксированным и
ограниченным числом итераций. Для выявления тестируемых маршрутов
в такой ациклической программе разработчик должен указать крите-
рий, по которому следует формировать маршруты. Упорядочение марш-
рутов производится по длительности их исполнения или по вероят-
ности реализации при случайных данных на входе программы. Если
ряд маршрутов может быть нереализуемым, то такие маршруты целесо-
образно исключить из последующего анализа. я_Исполнение систем по отладочному заданию.я. Специфика исполне-
ния программ при тестировании состоит в том, что на любом шаге
должна быть доступна информация о ходе и результатах процесса ре-
ализации программы. Необходимо иметь возможность я1выделять, ре-
я1гистрировать и отображать я0эту информацию в форме, удобной для
анализа и обобщения. Для этого должен быть нарушен естественный
ход исполнения программы для выполнения процедур регистрации ее
состояния и полу чаемых результатов. Для регистрации результатов
исполнения каждого оператора необходимо разорвать ход их естест-
венного исполнения в процессоре ЭВМ и вставить операторы регист-
рации. Это можно сделать двумя способами: методом вставок (компи-
ляции) и методом моделирования (интерпретации) каждой команды. При я2методе вставок (компиляции) я0заранее выделяются в тесте
программы контролируемые операторы и после каждого из них встав-
ляется текст регистрирующей программы или операторов перехода на
группу программ регистрации, обработки и отображения промежуточ-
ных данных. Текст отлаживаемой программы при этом расширяется и
деформируется за счет операторов регистрации. я2Метод моделирования я0(интерпретации) исполнения тестируемых
программ позволяет использовать текст программы в объектном коде,
каждая команда которой моделируется в соответствии с логикой опе-
раций данной ЭВМ. я_Системы автоматизации отладки программ.я. Для определенной со-
вокупности программных модулей с учетом их сложности, общего чис-
ла, требований к качеству и т.д. целесообразна такая я2степень ав-
я2томатизации отладкия0, при которой затраты на автоматизацию оправ-
дываются достигаемым сокращением длительности и стоимости разра-
ботки модулей, составляющих систему. К системе автоматизации
предъявляются следующие требования: - обеспечивать доступ пользователей в пакетном и диалоговом
режимах, представление данных в символьном и графическом видах и
в основном безбумажное проектирование программ; - использовать достаточно развитую БД проектирования для для
накопления информации о разрабатываемых программах, их версиях,
планах тестирования, тестовых и эталонных данных, выполненных
корректировках; - позволять автоматически выявлять большинство ошибок, обус-
ловленных нарушениями формализованных правил структурного постро-
ения модулей и использования данных; - обеспечивать автоматизированное планирование тестирования
и подготовку рекомендаций по систематическому применению методов
и стратегий тестирования с целью достижения максимальной коррект-
ности или надежности программ в условиях ограниченных ресурсов,
выделяемых на отладку; - позволять проводить автоматизированное тестирование прог-
раммных модулей, в том числе без деформации исполняемых программ
операторами отладки; - позволять оценивать достигнутую корректность программного
модуля по выбранным критериям тестирования и определять основные
конструктивные показатели качества (логическую и информационную
сложность, сложность связей, длительность счета и т.д.) созданных
программ; - осуществлять регистрацию всех выполненных изменений в
программах и учет версий программ, в которых проведены те или
иные корректировки. 21. Комплексная отладка АЭИС; задачи комплексной отладки;
статическая и динамическая комплексная отладка; регистрация и об-
работка данных при отладке программ (28.1). Основная задача комплексной отладки программ состоит в за-
вершении разработки всей АЭИС и в доведении ее характеристик до
значений, заданных требованиями ТЗ. Должны быть: - завершены и проверены сопряжение и взаимодействие по пере-
даче управления и по информации всех компонент, входящих в АЭИС; - проверена возможность получения в процессе рабочего функ-
ционирования АЭИС всех характеристик, заданных требованиями ТЗ, а
также вспомогательных, обоснованных в техническом проекте; - проверены полнота и состав технической документации, а
также точное соответствие ее изделию - АЭИС. Наиболее сложным является обеспечение возможности функциони-
рования АЭИС с характеристиками, заданными требованиями ТЗ и нор-
мативными документами. Система должна гарантированно удовлетво-
рять всем требованиям не только в диапазоне типичных условий
функционирования, но и при предельных, критических сочетаниях
значений всех параметров. Это обеспечивает надежность функциони-
рования программ при разнообразных произвольных, в т.ч. искажен-
ных сочетаниях исходных данных. В процессе комплексной отладки
должна быть обеспечена и проверена модернизируемость системы и
отработаны технические условия, обеспечивающие полный контроль
АЭИС при серийном производстве. Каждая функционально законченная
группа программ проходит отладку "от простого к сложному" до
уровня, позволяющего проверить удовлетворение требований ТЗ. Важнейшим принципом комплексной отладки является последова-
тельное сопряжение программных модулей, начиная с наиболее прос-
тых по решаемым задачам и имеющих минимальные связи. Комплексную
отладку можно разделить на три автономных этапа: - статическую комплексную отладку функциональных групп прог-
рамм вне реального времени; - комплексную отладку в реальном времени функциональных
групп программ и всей АЭИС без использования реальных объектов
управления и источников информации; - динамическую комплексную отладку АЭИС в реальном времени и
в реальной системе управления. я_Статическая комплексная отладкая. обеспечивает проверку и кор-
ректировку условий сопряжения, определяющих взаимодействие от-
дельных программных компонент по информации и по управлению. При
этом не полностью учитывается последовательность включения и ре-
шения различных функциональных задач во времени. По сравнению с
автономной отладкой объем одновременно функционирующих программ
при этом увеличивается, однако в каждый момент времени проверяет-
ся только одна определенная функциональная группа программ. Отладка состоит в контроле и обеспечении идентичности соста-
ва и характеристик информации, подготавливаемой каждой из сопря-
гаемых программ, данным, которые необходимы для правильного функ-
ционирования на входе другой стыкующейся программы в некоторые
фиксированные моменты времени. я1Идентичность выдаваемой и ожидае-
я1мой информации я0обеспечивается для каждой пары связей сопрягаемых
программ и при любом варианте их взаимодействия. При статической отладке контролируются: - структурная схема АЭИС, определяющая точку взаимодействия
и иерархию исполнения программ по передачам управления; - информационная схема АЭИС, отражающая реальные связи прог-
рамм через глобальные переменные и константы; - список всех возможных маршрутов исполнения групп функцио-
нальных программ, входящих в состав АЭИС. Первоначальный анализ структурной и информационной схем АЭИС
может быть проведен по спецификациям на программы, хранящимся в
БД. Последующее уточнение структурной схемы по управлению при не-
обходимости может проводиться в процессе опытного программирова-
ния, когда каждая программа заменяется имитатором, содержащим
операторы входа, выхода и вызова других программ. Для отработки информационной схемы взаимодействия программ в
имитаторы могут вводиться описания используемых переменных. Окон-
чательный контроль правильности организации разработки осущест-
вляется по готовым программам, которые по мере разработки заменя-
ют соответствующие имитаторы. Чтобы обеспечить последовательный
контроль правильности объединения программ, в комплексе первона-
чально ведется работа по отдельным группам программ. Для определения информационных связей между программами пре-
дусмотрено для заданных глобальных переменных получать перечень
программ из числа присутствующих в архиве, которые используют эти
переменные. При выдаче данных по информационным связям для каждой
программы указывается вид использования переменной (чтение, за-
пись или то и другое). Информационная схема может служить для
контроля обработки информации при параллельных вычислениях и, в
частности, для определения точек расстановки семафоров. я_Принципы имитации внешней среды в реальном времения.. При от-
ладке сложных АЭИС необходимо большое количество исходных данных
и эталонных значений для анализа результатов тестирования. Ручная
подготовка всего множества тестов нерентабельна, а во многих слу-
чаях практически невозможна. Использование реальных объектов и
натурных экспериментов для получения тестовых данных обычно свя-
зано с большими затратами и значительно ограничивает реально по-
лучаемый объем генерируемых тестов. В связи с этим для тестирова-
ния системы в качестве источников тестов и эталонных данных ис-
пользуются программные модели и имитаторы. Программные имитаторы внешней среды в зависимости от типа
(П)ЭВМ, на которой они реализуются, подразделяются на совмещенные
с отлаживаемой программой в одной ЭВМ и разделенные. Наиболее
сложными являются являются я1генераторы тестовых данных для отладки
я1и испытаний комплексов программ я0в реальном времени. Такие прог-
раммные имитаторы дают возможность создания тестов во всем много-
образии поведения объектов внешней среды данной АЭИС. При программной реализации процессов имитации информации и
обработки результатов тестирования необходимо время, затраты ко-
торого не должны искажать реальное время функционирования систе-
мы. решить эту задачу можно тремя способами: При я1первом способея0 предполагается, что затраты времени на
генерацию тестов и обработку результатов малы, не искажают реаль-
ного времени и могут производиться незадолго до их выдачи вне
связи с реальным временем функционирования АЭИС. Подготовленная
при имитации тестовая информация должна содержать время, на кото-
рое она рассчитана и когда она должна быть введена для использо-
вания в системе. Таким образом обеспечиваются функционирование
системы с полной имитацией реального времени и возможность кор-
ректного моделирования обратных связей взаимодействия тестируемой
системы с внешними объектами. В тех случаях, когда время, необходимое для генерации тестов
и обработки результатов, настолько велико, что не обеспечивается
темп поступления информации, можно использовать я1второй способ
(штриховые линии на рисунке) взаимодействия с имитаторами через
проежуточные носители информации. Имитируемая информация заранее
накапливается в имитирующей ЭВМ со значениями времени, которым
она соответствует (псевдореальное время, а затем переписывается
на специальные носители информации. Таким образом обеспечивается
ввод информации в тестируемую АЭИС и вывод результатов; однако
затруднена имитация обратных связей и реакции внешней среды на
управляющие воздействия от тестируемой АЭИС, т.к. моделирование
данных от объектов производится предварительно, вне реального
времени. Совмещение двух способов взаимодействия генераторов тестов с
тестируемыми АЭИС позволяет заранее имитировать основные потоки
тестовых данных с высокой интенсивностью и дополнительно учиты-
вать обратные связи от тестируемой АЭИС. я1Третийя0, стартстопный, я1способя0 позволяет использовать для ими-
тации и обработки тестов основную ЭВМ с тестируемой АЭИС, когда
невозможно обеспечить решение вспомогательных задач в реальном
времени. Для этого реальное время сохраняется только при решении
задач отлаживаемой системы, а решение задач генерации тестов про-
исходит вне счета реального времени. При этой схеме имитации мо-
гут корректно моделироваться управляемые объекты с учетом обрат-
ных связей от АЭИС. Однако при стартстопном режиме имитации ре-
ального времени затруднено смешанное моделирование с частичным
использованием реальных объектов -источников информации. я_Динамическая отладка системы с использованием имитацион-
я_но-моделирующих стендовя.. Наиболее сложными являются динамическая
отладка в реальном времени сложных АЭИС, управляющих реальными
объектами, и имитация тестов при следующих требованиях: - необходимо формировать большое количество разнородных тес-
товых сообщений в ограниченное время; - ряд тестовых данных зависит от информации, выдаваемой
комплексом программ, и должен формироваться оперативно с учетом
обратной связи от результатов обработки предыдущих тестов; - необходимо обеспечивать контроль генерируемых тестов, ре-
гистрацию эталонных данных и характеристик искусственных искаже-
ний, дополняемых к эталонным при подготовке тестов; - некоторые типы тестов содержат коррелированные логические
величины, сложно связанные между собой, которые необходимо также
корректно имитировать, как и квазинепрерывные переменные; - следует обеспечить полную повторяемость серий генерируемых
тестов при обнаружении аномалий в функционировании АЭИС. При этом широко применяются имитационные комплексы на техно-
логических ЭВМ, предназначенных для генерации тестов и обработки
результатов тестирования, - я_комплексные имитационно-моделирующие
я_стендыя.. Имитация стохастических тестов может быть представлена сле-
дующими достаточно автономными частями: имитацией эталонных дан-
ных и имитацией случайных ошибок, искажений и пропусков данных.
Эти данные затем объединяются по некоторым правилам и должны
обеспечивать подготовку подготовку сообщений с динамическими и
статическими характеристиками, максимально приближающимися к ре-
альным. Эталонные данные и характеристики сформированных искаже-
ний в большинстве случаев обрабатываются и используются при оцен-
ке результатов отладки АЭИС. Значительную сложность для генерации тестов представляют
коррелированные логические переменные и различные воздействия от
человека-оператора. Автоматическая программная имитация таких
данных обычно весьма сложна. Это приводит к необходимости созда-
ния специальных стендов, близких к реальной аппаратуре системы
обработки информации. Такие стенды позволяют дополнить автомати-
ческую имитацию основной массы тестов реальными данными от чело-
века, контролирующего функционирование системы управления и обра-
ботки информации. Для решения этой задачи стендовая аппаратура
сопрягается с имитирующей ЭВМ. Это требует разработки программно-
го обеспечения для отображения информации и ввода с пульта управ-
ления. я_Регистрация и обработка данных при отладке программя.. Для
анализа результатов отладки используются не только выходные дан-
ные программ, но и информация о реализации процесса их исполне-
ния. Для этого обеспечивается возможность регистрации и селекции
любых промежуточных данных, а также их связи с исходными тестами. я_Селекция результатов тестирования я.может базироваться на
стратегии контроля функционирования программ я2снизу вверхя0, т.е. от
анализа исполнения отдельных операторов программы и далее до сто-
хастических результатов функционирования АЭИС в динамике реально-
го времени. При этом регистрируется избыточное количество данных,
из которых затем отбирается минимум, необходимый для анализа.
Другая стратегия - я2сверху я0 я2вниз я0- базируется на упорядоченном,
иерархическом выделении в первую очередь обобщенных результатов
функционирования программ системы с последующим уточнением ре-
гистрируемых и анализируемых результатов вплоть до контроля ис-
полнения отмеченного программного модуля или отдельных операто-
ров. Данные, получаемые и выделяемые в процессе отладки АЭИС,
можно разделить на следующие группы: - данные, характеризующие исходную тестовую информацию и вы-
ходные маршруты тестирования; - маршруты исполнения групп программ при некоторых тестовых
данных; - промежуточные результаты исполнения отдельных выделяемых
операторов, модулей или групп программ; - аномальные события и данные, характеризующие отклонение
результатов тестирования за допустимые пределы и ограничения; - характеристики использования ресурсов (П)ЭВМ. Для получения этих данных в системе должны предусматриваться
средства регистрации и обработки промежуточных величин, необходи-
мых при отладке. Эти средства требуют ресурсов памяти и произво-
дительности ЭВМ. Их выделение может вызывать значительные труд-
ности, особенно в системах реального времени. Поэтому создаются
две категории средств: минимально необходимые для эксплуатацион-
ного контроля и средства более глубокого контроля для обнаруже-
ния, диагностики и локализации ошибок в процессе отладки. я_Оперативный анализ результатов я.стохастического тестирования
в реальном времени по выходным данным удобно проводить путем
представления их в графической форме с использованием дисплеев
или графопостроителей. В этом случае аномалии результатов тести-
рования хорошо наблюдаются по нарушению гладкости выходных графи-
ков или их отклонению от предполагаемых эталонных данных. Во всех случаях следует обеспечивать максимальную автоном-
ность регистрирующих программ и тщательно контролировать отсутс-
твие их влияния на основные функциональные модули и результаты их
исполнения. Целесообразно ограничивать контроль промежуточных ре-
зультатов, требующий нарушения целостности функционирования. В
отдельных случаях можно при разработке функциональных модулей
вставлять в них вызовы специальных программ для регистрации про-
межуточных результатов. Вызовы регистрирующих программ должны
подчиняться определенной системе контроля функционирования комп-
лекса программ при исходной гипотезе, что я_некоторое количество
я_ошибок в программах есть на любой стадии отладки и испытанийя.. Общим методом получения и анализа результатов является ие-
рархическое деление обрабатываемых данных на несколько уровней
детализации. Одной из основных задач обработки результатов тестирования
является получение по данным экспериментов статистических распре-
делений контролируемых величин. На практике во многих задачах
форма распределения повторяемых проверяемых параметров и показа-
телей качества оказывается заранее неизвестной. Однако часто в
качестве такого распределения можно предположить нормальный закон
распределения. Обработка результатов отладки АЭИС может быть разделена на
две автономные части: оперативную и обобщенную. я_Оперативная обработка результатов отладки я.производится по
упрощенным алгоритмам с большой пропускной способностью, обеспе-
чивающим сохранение реального времени для всего отлаживаемого
комплекса. Основная часть оперативной обработки результатов свя-
зана с замыканием контура обратной связи для имитации динамики
управляемых объектов. Оперативно следует производить селекцию не-
которых результатов тестирования и их предварительную обработку
для значительного сокращения объема хранимых результатов. В сос-
тав оперативной обработки целесообразно включать расчет части ин-
тегральных данных, позволяющих контролировать текущий процесс об-
работки информации и управления отлаживаемой АЭИС. Объем таких
оперативно отображаемых данных должен быть максимально сокращен-
ным и в то же время наглядно характеризующим систему. я_Обобщающая обработка накопленных результатов отладки может
производиться вне реального времени после завершения одного или
серии экспериментов. Основная задача при этом состоит в расчете
различных интегральных характеристик функционирования АЭИС. Неко-
торые эталонные данные могут быть получены от генераторов тестов.
При экспериментах с реальными объектами для получения эталонных
данных используются специальные измерительные комплексы. 22. Организация работ по проведению испытаний информационных
систем; организация проведения приемочных испытаний систем; осо-
бенности испытаний на надежность систем; достоверность определе-
ния качества систем при испытаниях; исходные и отчетные документы
при испытаниях систем (29.1). Испытания проводятся для сложных информационных систем (ИС),
создаваемых на уровне продукции производственно-технического наз-
начения и отчуждаемых от разработчика. Важной особенностью испы-
таний ИС - наличие достаточно полных эталонов, которым она должна
соответствовать - требований технического задания. Цель испытаний
- я_определение степени соответствия созданной АЭИС техническому
я_заданиюя., полученному от заказчика. Испытания, которыми завершается процесс проектирования ИС,
являются одним из важнейших этапов жизненного цикла, на котором
проверяются м фиксируются показатели качества системы. Для обес-
печения высокого качества АЭИС в ТЗ целесообразно задавать техно-
логию его проектирования и условия поэтапной проверки основных
компонент в процессе разработки. Для этого до начала разработки в
процессе формирования ТЗ формируются основы методики тестирования
и проверяемые характеристики системы при испытаниях. Для всесто-
ронней проверки опытный образец АЭИС подвергается предварительным
(под эгидой главного конструктора проекта), совместным (под эги-
дой заказчика-пользователя с участием разработчика) и межведомс-
твенным (с привлечением независимых экспертов) испытаниям. При предварительных испытаниях, которые обычно совмещаются с
завершением комплексной отладки, производится такое же тестирова-
ние, что и на совместных (межведомственных), только в меньшем
объеме. Все это оформляются документально и являются основанием
для предъявления АЭИС заказчику. Испытания ограничены допустимым
объемом проверок и длительностью работы приемочной комиссии, поэ-
тому не могут гарантировать всестороннюю проверку изделия. Для повышения достоверности требований и улучшения характе-
ристик после испытаний целесообразно на некоторое время передать
АЭИС на опытную эксплуатацию в типовых условиях. Это позволяет
оценить эксплуатационные характеристики системы и устранить ошиб-
ки. Опытная эксплуатация проводится разработчиками с участием ис-
пытателей и некоторых пользователей, назначаемых заказчиком. В жизненном цикле АЭИС можно выделить следующие виды испыта-
ний: опытного образца АЭИС на полное соответствие требованиям
технического задания; рабочей версии АЭИС, адаптированной к усло-
виям конкретного применения; версии модернизированной АЭИС при
сопровождении. Для обеспечения полноты приемосдаточных испытаний опытного
образца целесообразно выделять категории тестирования. я_я1Функциональное тестированиея.я0 - наиболее обширное и труднее
всего систематизируемое. Набор испытательных тестов определяется
функциональными задачами и сложностью АЭИС. Тесты должны обеспе-
чивать проверку и демонстрацию заказчику или пользователю качест-
ва решения функциональных задач, сформулированных в ТЗ и конкре-
тизированных в документации. Поскольку исчерпывающее тестирование
для сложных ПС невозможно, большое значение имеют уточнения об-
ластей варьирования тестовых данных и выделение областей их изме-
нений, наиболее важных для последующего использования систем. я_я1Стрессовое тестированиея.я0 (в критических ситуациях) базируется
на классификации областей определения исходных данных и использу-
ет граничные или экстремальные значения параметров и условий.
Комбинация критических значений и условий испытаний очень разно-
образна, и необходим тщательный анализ для выделения достаточно
представительной выборки. При стрессовых испытаниях должно быть
показано, что при изменении исходных данных за допустимыми преде-
лами эти ситуации обнаруживаются, селектируются и выдается диаг-
ностика о нарушении ограничений на условия эксплуатации программ. я_я1Тестирование использования ресурсов ЭВМя.я0 является частным
случаем стрессового тестирования. Внимание сосредоточивается на
исследовании зависимости объема памяти и длительности решения за-
дач от характеристик исходной информации. Определяются допустимые
размерность задач и интенсивности потоков исходных данных, при
которых возможно нормальное функционирование АЭИС. я_я1Тестирование параллельного решения задачя.я0 в многомашинных или
многопроцессорных комплексах состоит в испытаниях взаимодействия
программ и данных при одновременном исполнении компонент прог-
раммного комплекса. Испытания можно разделить на две части: при
детерминированных запланированных ситуациях; при случайном нор-
мальном функционировании программ. В первом случае основная проб-
лема состоит в создании представительного многообразия ситуаций
параллельного функционирования программ. Вторая часть тестирова-
ния может совмещаться с остальными видами испытаний и заключается
в основном в выделении случайных тестов и условий, при которых
проверяется недетерминированное параллельное исполнение программ. я_Особенности испытаний на надежность системя.. В теории надеж-
ности разработан ряд методов, позволяющих определять характерис-
тики надежности сложных систем. я2Прямые экспериментальные методы определения показателей на-
я2дежности систем я0в условиях функционирования весьма трудно исполь-
зовать при испытаниях из-за большого времени наработки на отказ
(десятки и сотни часов). Сложность выявления и регистрации редких
отказов, а также высокая стоимость экспериментов при длительном
функционировании АЭИС приводят к тому, что на испытаниях получа-
ются малые выборки зарегистрированных отказов. При испытаниях на надежность функционирования необходимо
разделять причины отказов и отказовых ситуаций на обусловленные
ненадежностью аппаратуры и ошибками в программах. Устойчивые от-
казы аппаратуры селектируются достаточно просто. Однако кратков-
ременные сбои в аппаратуре и последствия ошибок в программе тре-
буют тщательного анализа для выделения и диагностики их источни-
ка. Для этого может использоваться программа анализа сбоев, кото-
рая осуществляет первичный анализ и классификацию возможных ис-
точников аномалий функционирования. Для диагностики и локализации
причин отказа требуется дополнительное стохастическое и детерми-
нированное тестирование, позволяющее выделить первичную ошибку в
программе, или отнести источник отказа к сбою в аппаратуре. На этапе испытаний устраняются локализованные ошибки,
вследствие чего характеристики надежности системы в среднем улуч-
шаются. Однако возможны изменения в системе, связанные в основном
с корректировкой программ, которые ее ухудшат. Получаемые показа-
тели надежности позволяют прогнозировать число ошибок, подлежащих
исправлению для достижения заданной надежности. Для этого исполь-
зуются математические модели изменения ошибок и основных показа-
телей надежности в зависимости от длительности тестирования. При высокой надежности ИС организуются многочасовые прогоны
реального функционирования программ системы в условиях широкого
варьирования исходных данных. Такие прогоны позволяют измерить и
зафиксировать достигнутые показатели надежности и степень их со-
ответствия требованиям ТЗ, а также закрепить их в ТУ на АЭИС. я2Форсированные методы испытаний реальных систем на надежность
осуществляются путем тестирования при повышенной интенсивности
искажений исходных данных с широким варьированием их значений, а
также специальным увеличением загрузки выше нормальной. Планиро-
вание форсированных испытаний должны предусматривать последующий
пересчет полученных показателей надежности на условия нормального
функционирования. Особым видом форсированных испытаний является
тестирование эффективности средств контроля и восстановления
программ, данных и вычислительного процесса. Для этого имитируют-
ся запланированные экстремальные условия функционирования прог-
рамм, при которых в наибольшей степени вызываются средства прог-
раммного рестарта. При таких испытаниях основная задача состоит в
проверке качества функционирования средств повышения надежности. я_Достоверность определения качества систем при испытанияхя..
Задача испытателей и заказчика при планировании испытаний состоит
в выделении условий и областей изменения переменных, которые наи-
более важны для последующего использования системы. Разработчик
контролирует, чтобы планируемое тестирование не выходило из об-
ластей, заданных ТЗ. Испытания за пределами ТЗ могут квалифициро-
ваться как его расширение или могут исключаться по требованию за-
казчика. Важную роль играют оценка и обеспечение близких значений
методической и статистической достоверностей испытаний. я1Методическая достоверность я0испытаний АЭИС определяется фак-
торами: полнотой программы испытаний, корректностью методик тес-
тирования, степенью охвата возможных условий функционирования и
областей изменения исходных данных информационных систем; досто-
верностью и точностью эталонных значений, с которыми сравнивают
результаты тестирования испытываемой системы или которые служат
опорными при расчете параметров, зафиксированных в ТЗ; адекват-
ностью и точностью моделей, используемых для имитации внешней
среды и их реакции на управляющие воздействия; точностью и кор-
ректностью регистрации и обработки результатов тестирования, а
также сравнения полученных данных с требованиями ТЗ. я1Статистическая достоверность я0испытаний в значительной степе-
ни ограничена допустимым объемом и продолжительностью испытаний.
Методы теории планирования экспериментов позволяют упорядоченно
варьировать исходные данные и наиболее эффективно использовать
ограниченные ресурсы тестирования. При планировании испытаний
большое значение имеют характеристики средств автоматизации, ис-
пользуемых для имитации внешней среды и обработки результатов.
Противоречия между необходимой степенью достоверностью тестирова-
ния и объемом анализируемых данных при различных видах испытаний
привели к созданию системы автоматизации испытаний различной
сложности и глубины проверок. я_Исходные и отчетные документы при испытаниях системя.. Сов-
местные испытания проводятся комиссией заказчика, в которой учас-
твуют главный конструктор разработки и отдельные ведущие разрабо-
тчики. Комиссия при испытаниях руководствуется следующими докуме-
нтами: утвержденным заказчиком и согласованным с разработчиком ТЗ
на разработку системы;действующими государственными и отраслевыми
стандартами на проектирование и испытания систем и на техническую
документацию; программой испытаний по всем требованиям ТЗ; мето-
диками испытаний по каждому разделу требований ТЗ. Программа испытаний, методики их проведения и оценки резуль-
татов разрабатываются совместно заказчиком и разработчиком, долж-
ны быть согласованы и утверждены. Они содержат уточнения требова-
ний ТЗ для данной системы и должны гарантировать их корректную
проверку. Документация на систему должна соответствовать испыты-
ваемым программам и аппаратуре, обеспечивать познаваемость систе-
мы обслуживающим персоналом, а также обеспечивать возможность
развития и модернизации АЭИС для увеличения ее жизненного цикла. я_Программа испытаний я.- это план проведения серии эксперимен-
тов, разрабатываемый с позиции минимизации объема тестирования
при заданной и согласованной с заказчиком достоверности получае-
мых результатов. Методами факторного анализа и теории планирова-
ния экспериментов определяются последовательность и объем тести-
рования в процессе проведения испытаний для проверки выполнения
требований ТЗ при минимальных затратах. Программа испытаний долж-
на содержать следующие четко сформулированные разделы: - я1объект испытанийя0, его назначение и перечень основных до-
кументов, определивших его разработку; - я1цель испытаний я0с указанием основных требований ТЗ, подле-
жащих проверке, и ограничений на проведение испытаний; - собственно я1программу испытанийя0, содержащую проверку комп-
лектности спроектированной АЭИС в соответствии с ТЗ и план тести-
рования для проверки функционирования систем по разделам ТЗ и до-
полнительным требованиям, формализованным отдельными решениями; - я1метя0оя1дики испытанийя0, однозначно определяющие все понятия
проверяемых характеристик, условия тестирования, средства, ис-
пользуемые для испытаний, методики обработки и оценки результатов
тестирования по каждому разделу программы испытаний. Большой объем разнородных данных, получаемых при испытаниях
ПС, и разнообразие возможных способов их обработки, интерпретации
и оценки приводят к тому, что важнейшими факторами для обработки
результатов тестирования становятся я_методики обработки и оценки
я_результатовя.. В соответствии с методиками испытаний средства авто-
матизации должны обеспечивать полноту проверок характеристик по
каждому разделу методик и разработку я_протоколов проверки я.по пунк-
там программы испытаний. Сложность системы и сильная взаимосвязь
между их характеристиками приводят к необходимости тщательной
формулировки всех условий тестирования и значений параметров, при
которых должна производиться проверка. я_Результаты испытанийя. фиксируются в протоколах, которые обыч-
но содержат следующие разделы: назначений тестирования и раздел
требований ТЗ, по которому проводятся испытания; указания мето-
дик, в соответствии с которыми проводились испытания, обработка и
оценка результатов; условия проведения тестирования и характерис-
тики исходных данных; обобщенные результаты испытаний с оценкой
их на соответствие требованиям ТЗ и другим руководящим докумен-
там; выводы о результатах испытаний и степени соответствия соз-
данной АЭИС определенному разделу требований ТЗ. Протоколы по всей программе испытаний обобщаются в акте, в
результате чего делается заключение о соответствии системы требо-
ваниям заказчика и о завершении работы с положительным или отри-
цательным результатом. При полном выполнении всех требований ТЗ
заказчик обязан принять систему и работа считается завершенной. Для сложных АЭИС трудно на начальных этапах проектирования
предусмотреть и корректно сформулировать все требования ТЗ. Поэ-
тому при отладке и испытаниях часто выявляется, что некоторые
требования ТЗ оказываются невыполненными и иногда даже принципи-
ально не могут быть выполнены при самом добросовестном отношении
к этому со стороны разработчика. В этом случае необходима сов-
местная работа заказчика и разработчика в поисках компромиссного
решения при завершении испытаний и составления заключения. Неко-
торые недостатки системы в процессе испытаний регистрируются и
фиксируются в плане устранения замечаний комиссии, проводившей
испытания. План является приложением к акту о результатах испыта-
ний и позволяет отделять последующие доработки от непосредствен-
ных испытаний.
23. Организация работ по сопровождению информационных сис-
тем; задачи сопровождения; иерархия подготовки и внесения измене-
ний в систему; тиражирование и использование версий системы
(30.1.). Программы в составе информационных систем являются одним из
наиболее гибких видов продукции, которые эпизодически подвергают-
ся изменениям в течение всего времени их использования. Иногда
достаточно при корректировке внести одну ошибку для того, чтобы
резко снизилась надежность программы или ее корректность при не-
которых исходных данных. Для сохранения и повышения качества сис-
темы необходимо регламентировать процесс модификации и поддержи-
вать его соответствующим тестированием и контролем качества. В
результате АЭИС со временем обычно улучшается как по функциональ-
ным возможностям, так и по качеству решения отдельных задач. Работы, обеспечивающие контроль и повышение качества, а так-
же развитие функциональных возможностей систем, составляют я_про-
я_цесс сопровожденияя., включающий: - я1исправления ошибок я0- корректировка программ, выдающих неп-
равильные результаты в условиях, ограниченных ТЗ и документацией;
в процессе сопровождения требуют около 20 % затрат; - регламентированная документами я1адаптация я0к условиям конк-
ретного использования, обусловленным характеристикам внешней сре-
ды или конфигурацией аппаратных средств, на которой предстоит
функционировать программам, - около 20 % общих затрат; - я1модернизация я0- расширение функциональных возможностей или
улучшение характеристик решения отдельных задач в соответствии с
новым или дополненным ТЗ на АЭИС - до 60 % общих затрат. Первый вид изменений является непредсказуемым и его трудно
регламентировать. Остальные виды корректировок носят упорядочен-
ный характер и проводятся в соответствии с заранее подготавливае-
мыми планами и документами. Эти корректировки в наибольшей степе-
ни изменяют компоненты системы и требуют наибольших затрат. Со временем, иногда через десятки лет, сопровождение системы
прекращается. Это может быть обусловлено разработкой более совер-
шенных систем, прекращением использования сопровождаемой системой
или нерентабельным возрастанием затрат на сопровождение. Для то-
го, чтобы со временем прийти к обоснованному решению о прекраще-
нии сопровождения, необходимо периодически оценивать эффектив-
ность эксплуатации и возможный ущерб от отмены сопровождения (в
отдельных случаях решение о прекращении сопровождения принимается
при противодействии со стороны отдельных пользователей). я_Иерархия подготовки и внесения изменений в системуя.. Некор-
ректные изменения эксплуатируемых систем могут вызвать значитель-
ный ущерб; поэтому необходимо их селектировать и тщательно прове-
рять. На завершающих стадиях комплексной отладки в процессе экс-
плуатации и сопровождения сложных АЭИС применяются я_методы конфи-
я_гурационного управленияя., которое необходимо и особенно эффективно
при сопровождении широко тиражируемых сложных АЭИС, используемых
одновременно в нескольких версиях. Ошибки и предположения изменений первоначально селектируются
специалистами по компонентам АЭИС и анализируются советом конфи-
гурационного управления по их влиянию на качество функционирова-
ния программ системы и затратам на осуществление изменений. Каж-
дое я_предлагаемое изменение системыя. оценивается по следующим кри-
териям: насколько данное изменение может улучшить эксплуатацион-
ные характеристики АЭИС в целом; каковы затраты на выполнение
корректировок в новой версии и их распространение пользователям;
возможно ли и насколько сильно влияние изменения на функциональ-
ные характеристики остальных компонент данной АЭИС; какова сроч-
ность извещения пользователей о разработанной корректировке и це-
лесообразно ли ее распространять до подготовки очередной версии;
для какого числа пользователей может быть полезным данное измене-
ние; как данное изменение отразится на эксплуатации пользователя-
ми предыдущих версий; насколько подготовка данного изменения мо-
жет отразиться на сроках создания очередной версии. В результате анализа часть предлагаемых изменений отвергает-
ся, а для тех, которые отобраны для реализации, разрабатываются
корректировки. Особое значение приобретает тестирование подготов-
ленных изменений и испытания выпускаемых версий. Основное тести-
рование сосредоточивается на проверке корректности каждой выпол-
ненной корректировки программ и на качестве функционирования ис-
пытываемой эталонной версии АЭИС. Проверка функционирования копий
ограничивается некоторым набором типовых контрольных задач. В процессе эксплуатации текущей версии АЭИС у пользователя
выявляются некоторые претензии к функционированию, которые поль-
зователем обычно квалифицируются как ошибки эталонной или собс-
твенной версии. Ряд таких аномалий обусловлен недостаточной ква-
лификацией пользователя. Для установления достоверности сообщений
о выявленных ошибках производится регистрация условий, при кото-
рых проявляются аномалии, и предварительное тестирование версии
программ для селекции неподтверждающихся ошибок. Часть претензий
оказывается не связанной с корректностью систем и возникает
вследствие недостаточной квалификацией пользователя, из-за недос-
татков документации на АЭИС, или вследствие сбоев в аппаратуре. От пользователя могут поступать предложения по внесению из-
менений в текущую версию для улучшения эксплуатационных характе-
ристик и расширения функциональных возможностей АЭИС. Такие же
предложения могут поступать от разработчиков системы. На базе
предложений создается документ - исходные данные для планирования
доработок и тестирования системы в процессе сопровождения. Для общения с пользователями и накопления информации о выяв-
ляемых недостатках в широко тиражируемых сложных АЭИС целесооб-
разно выделение группы специалистов высокой квалификации, овла-
девших всеми функциональными возможностями данной АЭИС, имеющая в
своем арсенале весь комплекс тестов, применявшихся при испытаниях
опытного образца и предыдущих версий АЭИС для я_антирегрессионного
я_тестированияя.. Эти тесты накапливаются, упорядочиваются и катало-
гизируются в БД тестирования. Для повышения качества очередных версий руководитель сопро-
вождения и совет конфигурационного управления анализируют все
предлагаемые изменения. В процессе анализа все я_предполагаемые из-
я_менения селектируютсяя. на группы: срочные, которые должны быть не
только внесены в очередную версию АЭИС, но и сообщены пользовате-
лю для оперативной корректировки программ до внедрения официаль-
ной версии; изменения, которые целесообразно внести в текущую
версию с учетом затрат на их реализацию и улучшения эффективности
АЭИС; изменения, которые требуют дополнительного анализа целесо-
образности и эффективности их реализации в последующих версиях и
могут не внедряться в ближайшую текущую версию; изменения, кото-
рые не оправдывают затрат на разработку и выполнение корректиро-
вок или практически не влияют на эффективность АЭИС, вследствие
чего не подлежат реализации. Для принятых к внедрению изменений разрабатывается план до-
работок программ. Изменения системы могут потребовать полной за-
мены модуля (группы программ), или небольшого изменения текста
программного модуля, описания данных или констант. Если изменения
в программах системы или данных невелики, то тестирование ограни-
чивается компонентами, непосредственно связанными с выполненной
корректировкой (корректировки сами могут содержать ошибки и сами
требуют тестирования). Наличие в системе межмодульных связей по
управлению и по информации вызывают необходимость тестирования
тех компонент, где по первому впечатлению корректировки не оказы-
вают влияния. Это приводит к появлению вторичных ошибок вследс-
твие проведенных изменений и нарушения функциональной целостности
группы взаимодействующих программ и данных. я_Тиражирование и использование версий системыя.. Все корректи-
ровки предварительно выполняются и проверяются на версиях систем
разработчиков. Откорректированные версии компонент подвергаются
автономному тестированию, после чего объединяются в группы прог-
рамм системы и тестируются в скомплексированных группах. Объединение групп откорректированных систем позволяет соз-
дать эталон версии АЭИС, подлежащий тестированию по программе ис-
пытаний. Сложность испытаний зависит от объема выполненных изме-
нений и при большом их количестве может приближаться к испытаниям
опытного образца. Объем тестирования при испытаниях текущей вер-
сии согласуется разработчиком и заказчиком или основными пользо-
вателями. Все проверенные и подтвержденные при испытаниях измене-
ния регистрируются и утверждаются, после чего оформляются доку-
ментация и магнитные носители подлинника текущей версии, которая
передается на тиражирование и внедрение у пользователей. При создании опытного образца АЭИС могут предусматриваться в
(П)ЭВМ некоторые резервы ресурсов для последующего развития сис-
темы. Обычно эти ресурсы обеспечиваются за счет исключения неко-
торых компонент программ системы, что обеспечивает освобождение
необходимого объема памяти команд и данных, а также сокращение
длительности счета при решении заданного комплекса задач. В процессе разработки текущей версии АЭИС используются вер-
сии подсистем, переписываемых из предыдущих версий. Все версии
разработчиков сопровождаются дубликатами, которые эпизодически
тестируются на соответствие основной версии разработчика. Коррек-
тировку компонент и сборку очередной версии производят специалис-
ты, ответственные за сопровождение с привлечением разработчиков
предыдущих версий подсистем. Версия, прошедшая испытания, после оформления акта испытаний
и окончательной корректировки документации превращается в подлин-
ник, который снабжается техническими условиями и тестами для про-
верки его полной сохранности и функциональной работоспособности.
Для сохранения подлинника обеспечиваются особые условия его хра-
нения и периодическое (с интервалами полгода - год) тестирования
для проверки сохранности и работоспособности системы. При выпуске каждой новой версии стремятся обеспечить преемс-
твенность ее функций с предыдущими, а также рассматривается воз-
можность прекращение сопровождения некоторой ранней версии систе-
мы. В результате среди всего множества версий каждой АЭИС образу-
ется зона сопровождаемости версий. число таких сопровождаемых
эталонных версий или глубина сопровождения практически всегда не
более двух версий и редко превышает четыре версии.
ля сложных
АЭИС это соответствует рациональному жизненному циклу, который
составляет 3..5 лет. Полный жизненный цикл каждой версии может
составлять 20..30 лет, а суммарное число эталонных версий - дос-
тигать 20. В ряде областей применения ПС требуются высокие гарантии ка-
чества функционирования допускаемых к использованию версий прог-
рамм. Такие гарантии качества ПС необходимы, например, при акту-
альности решения задачи, от которой зависит работа предприятия. В
таких случаях недопустимы аномалии функционирования систем при
любых искажениях исходных данных, сбоях аппаратуры и других неш-
татных ситуациях. Качество АЭИС должно быть не только проверено
разработчиками и пользователями, но и удостоверено особо квалифи-
цированными специалистами, имеющими право на государственную или
ведомственную я_сертификациюя.. Методы сертификации в значительной степени подобны методам
тестирования при отладке и испытаниях системы. Основное отличие
состоит в более широком варьировании всех исходных данных в усло-
виях функционирования системы. Для этого необходимы адекватные
модели внешней среды, обеспечивающие весь спектр исходных данных
для сертификации. Кроме того специалисты, проводящие сертификацию
должны быть независимы от разработчиков, заказчиков и будущих
пользователей АЭИС. Эти специалисты имеют право на расширение ус-
ловий испытаний и на создание нештатных ситуаций для функциониро-
вания программ, при которых система должна обеспечивать необходи-
мое качество решения задач. При успешных результатах проверок определенной версии АЭИС
на нее оформляется специальный документ - я_сертификатя..
предыдущие вопросы
С помощью метода анализа иерархий решите вопрос о распределении ограниченного объема средс. Дисциплина организация и функционирование экономических информационных систем. Оценка завершенности отладки программ по экономическим критериям. Решение экзаменационных задач по дисциплине гостиничный бизнес. Программа по дисциплине эксплуатация информационных систем. Вопросы к экзамену Проектирование вычислительных систем. Проектирование информационно экономической системы. Образец составления ТЗ на информационную систему. Обработка статической экономической информации. Программа Проектирование информационных систем. Зарезервированные имена внешних устройств это. Дисциплина проектирование приборов и систем. Экзаменационные билеты для проектировщиков. Этапы технологическое проективание ЭИС. Ответы на билеты проектирование ЭИС.