Информация о готовой работе

Бесплатная студенческая работ № 8

Мировая экономика - широко разветвленная научная отрасль, имеющая мощную информационную базу (только в США выходит более 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. В ряде областей применения ПС требуются высокие гарантии ка- чества функционирования допускаемых к использованию версий прог- рамм. Такие гарантии качества ПС необходимы, например, при акту- альности решения задачи, от которой зависит работа предприятия. В таких случаях недопустимы аномалии функционирования систем при любых искажениях исходных данных, сбоях аппаратуры и других неш- татных ситуациях. Качество АЭИС должно быть не только проверено разработчиками и пользователями, но и удостоверено особо квалифи- цированными специалистами, имеющими право на государственную или ведомственную _сертификацию .. Методы сертификации в значительной степени подобны методам тестирования при отладке и испытаниях системы. Основное отличие состоит в более широком варьировании всех исходных данных в усло- виях функционирования системы. Для этого необходимы адекватные модели внешней среды, обеспечивающие весь спектр исходных данных для сертификации. Кроме того специалисты, проводящие сертификацию должны быть независимы от разработчиков, заказчиков и будущих пользователей АЭИС. Эти специалисты имеют право на расширение ус- ловий испытаний и на создание нештатных ситуаций для функциониро- вания программ, при которых система должна обеспечивать необходи- мое качество решения задач. При успешных результатах проверок определенной версии АЭИС на нее оформляется специальный документ - _сертификат ..

ВОПРОСЫ к билетам государственных экзаменов (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.).

Вы можете приобрести готовую работу

Альтернатива - заказ совершенно новой работы?

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

Blog

Информация о готовой работе

Бесплатная студенческая работ № 8

Вы можете приобрести готовую работу

Альтернатива - заказ совершенно новой работы?