Лекция 6

Основные компоненты САПР

1. Организационное обеспечение САПР

2. Информационное обеспечение САПР

3. Программное обеспечение САПР

4. Документирование программного обеспечения

5. Надежность программного обеспечения

1 Программное обеспечение САПР

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

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

В ПО АС принято выделять общесистемное ПО, системные среды и прикладное ПО.

К общесистемному ПО относят операционные системы (ОС) используемых ЭВМ и вычислительных систем и сетевое ПО типовых телекоммуникационных услуг.

Различают ОС со встроенными сетевыми функциями и оболочки над локальными ОС. В соответствии с другим признаком классификации сетевые ОС подразделяют на одноранговые и функционально несимметричные (ОС для систем клиент-сервер).

Основные функции сетевой ОС:

- управление каталогами и файлами;

- управление ресурсами;

- коммуникационные функции;

- защита от несанкционированного доступа;

- обеспечение отказоустойчивости;

- управление сетью.

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

Управление ресурсами включает в себя функции запроса и предоставления ресурсов.

Коммуникационные функции обеспечивают адресацию, буферизацию, маршрутизацию сообщений.

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

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

Чем сложнее сеть, тем острее встают вопросы управления сетью. Основные функции управления сетью реализуются в ПО, поддерживающем протоколы управления такие, как IСМР и SNМР в стеке ТСР/1Р или протокол СМ1Р (Соmmon Маnаgement Information Ргоtokol) в семиуровневой модели ISO. Как рассмотрено выше, это ПО представлено менеджерами и агентами. Менеджер - прикладная программа, выдающая сетевые команды. Агенты доводят эти команды до исполнительных устройств и сигнализируют о событиях в состоянии устройств, они следят за трафиком и фиксируют аномалии, помогают восстановлению информации после сбоев, борются с вирусами и т.п.

В сетевых ОС обычно выделяют ядро, реализующее большинство из перечисленных функций и ряд дополнительных программ (служб), ориентированных на реализацию протоколов верхних уровней, организацию распределенных вычислений и т.п. К сетевому ПО относятся также драйверы сетевых плат, различные для разных типов ЛВС (Ethernet, ТR, АррlеТаlк и др.).

В настоящее время выбор среди ОС происходит преимущественно между тремя основными операционными системами - UNIX, Windows NT, Novе11 Netwаге.

Областью применения ОС UNIX остаются крупные корпоративные сети со стеком протоколов ТСР/1Р Отличительные свойства UNIX - высокая надежность, возможность легкого масштабирования сети.

Windows NT предназначена для работы в сетях клиент-сервер, ориентирована преимущественно на рабочие группы и средние по своим масштабам сети. ОС асимметрична - включает в себя серверную (Windows NT Server) и клиентскую (Windows NT Workstation) части.

Novе11 Netwаге пока сохраняет свои позиции в небольших сетях. Состоит из серверной части и оболочек Shе11, размещаемых в клиентских узлах.

Программное обеспечение САПР – совокупность программ и эксплуатационной документации к ним необходимых для выполнения автоматизированного проектирования. ПО делится на общесистемное (общее) и специальное (прикладное).

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

Специальное (прикладное) ПО реализует математическое обеспечение непосредственно для выполнения проектных процедур.

Типичная структура ПО современных САПР выглядит следующим образом (рис.2). Пользовательский интерфейс включает текстовый и графический редакторы и поддерживается системами многооконного интерфейса (Х WINDOW SYSTEM, OPEN LOOK, WINDOWS и т.д.).

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

-слежения за состоянием проекта;

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

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

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

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

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

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

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

Названные подсистемы выполняют обслуживающие функции, в современных САПР их объединяют в операционных средах.

Ещё одна черта ООП - иерархическая структура ПО с выделением общих объектов для некоторого класса процедур в отдельные базовые слои - характерна для большинства сложных программных систем в САПР. Следовательно, ООП можно рассматривать как удобное средство для решения проблемы интеграции ПО в САПР.

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

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

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

2 Надёжность программного обеспечения

Ввиду большого числа программ в САПР различной сложности актуальна задача обеспечения надёжности его (ПО) функционирования.

Для количественной оценки надёжности часто используют коэффициент оперативной готовности к_ог[6]:

К_ог=к_гР,

где к_г- коэффициент готовности программы к работе;

Р - вероятность её правильного функционирования в цикле работы системы.

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

Как правило, программа – резидент переписывается периодически из долговременного ЗУ в оперативную память, и перезапускается либо по сигналам аппаратного контроля, либо принудительно. Тогда

к_г= (1) , Т_нг=Т_со+Т_в,

Т₀- время, в течение которого программа- резидент обеспечивает готовность всей программы к работе.

Т_со- общее время существования в ней скрытых отказов;

Т_в- время восстановления программы- резидента.

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

Т_нг= _сб(1- ) _сб + ,

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

(1- )- вероятность срабатывания средств аппаратного контроля при возникновении сбоя;

- длительность однократного восстановления программы- резидента;

- среднее время существования скрытого отказа программы - резидента;

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

Из формулы (1) видно, что max К_г достигается при min , т.е. при

Анализ данной зависимости показывает, что она имеет один минимум. Для его отыскания продифференцируем функцию, приравняем к нулю, после чего получим

f

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

Например, при с^-1 (одно не обнаруживаемое нарушение за 80с - очень «плохая» величина, для современных ЭВМ не характерна). Тогда при с значение к_г 0,995.

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

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

1. Программа не обеспечивает решения задачи при нормальных условиях.

2. Программа не обеспечивает решения задачи при предельных значениях входных данных, в основном из-за аппаратных сбоев.

Тогда вероятность правильного функционирования программы будет определяться выражением

Р=Р₀Р⁽¹⁾+(1-Р₀)Р⁽²⁾,

гдеР₀- вероятность отсутствия во время работы аппаратных сбоев;

Р⁽¹⁾ - вероятность правильного функционирования программы в этих условиях;

Р⁽²⁾ - вероятность правильного функционирования программы при условии возникновения сбоев.

Надёжное функционирование программы обеспечивается:

- системой отладки (для достижения Р⁽¹⁾ 1 );

- временным резервированием вычислительного процесса, позволяющим повторно выполнить программу, начиная с некоторого момента (для достижения высокого Р⁽²⁾ ).

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

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

q- вероятность необнаружения аппаратного сбоя.

Для защищённых программ обычно =0, ® Р⁽²⁾=(1-q)Р⁽¹⁾, в этом случае Р=[1-(1-P₀)q]P⁽¹⁾ .

Например, при отладке программы достигают, как правило,

Р⁽¹⁾=0,98.Тогда при Р₀=0,9иq=0,1 Р=0,98.

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

4.2.4.4. Организационное обеспечение

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

Еще один важный организационный аспект функционирования создаваемой АС - временной регламент выполнения автоматизированных функций. Этот регламент определяет сроки решения задач ЛС. В совокупности с отражаемым в должностных инструкциях распределением задач по исполнителям, временной регламент дополняет схемы технологических процессов обработки данных информацией: кто, в какие сроки и при каких условиях должен решать каждую конкретную задачу. Сводный временной регламент выполнения автоматизированных функций АС в целом или отдельных подсистем приводится в проектном документе «Описание технологического процесса обработки данных», что позволяет комплексно выбирать рациональную последовательность решения задач с учетом причинно-следственных связей между ними, необходимостью использовать одни и те же ресурсы и т.п. Пример схематического изображения временного регламента выполнения автоматизированных функций изображен на рис. 4.¹).

Рис. 4.9. Временной регламент выполнения автоматизированных функций

4. Документирование программного обеспечения

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

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

Рис. 4.19. Программная документация на АС

С формальной точки зрения требования к документированию программного обеспечения в настоящее время определяются государственными стандартами 19 класса «Единая система программной документации» (ЕСПД). Большинство стандартов этого класса были разработаны и введены в действие еще в 70-80-х гг. XX в. На наш взгляд, регламентируемый ими подход к определению состава и содержания программной документации следует признать практически полностью устаревшим и не соответствующим ни современным концепциям создания и эксплуатации программного обеспечения, ни действующему законодательству в области охраны авторского права и смежных прав. Однако документировать программные решения необходимо, и в современных условиях мы вынуждены избирательно применять те положения стандартов и руководящих документов, которые не противоречат современным правовым актам. В частности, весьма полезным оказывается п. 1.3.4 ГОСТ 34.201, согласно которому разработчик имеет право «расширять номенклатуру документов, установленных настоящим стандартом».

Наиболее важными рабочими программными документами следует признать «Текст программы», «Руководство программиста», «Руководство администратора», а также технические инструкции.

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

«Руководство программиста» - документ, в котором детально описывается состав и структура оригинального ПО, режимы и особенности его функционирования, организация взаимодействия с пользователями, а также возможности и порядок корректировки и изменения программ. Этот документ дополняет «Текст программы» и используется, чаще всего, при развитии или модернизации АС либо при возникновении аварийных ситуаций, требующих анализа и изменения исходного кода программ. Для понимания логики написания и функционирования программ в «Руководстве программиста» должны быть изложены принятые в организации-разработчике стандарты программирования, соглашения о межмодульных связях, значения управляющих переменных и их семантика. Детально описываются связи с файловой системой ОС, взаимодействие с СУБД, пакетами программ и с периферийными устройствами. В описаниях модулей, реализующих сложные методы обработки данных, могут приводиться подробные алгоритмы реализации соответствующих действий. «Руководство программиста» ориентировано на высококвалифицированных специалистов в области информационных и коммуникационных технологий, поэтому при его написании должна использоваться строгая профессиональная терминология. Структура документа может строиться с учетом рекомендаций, изложенных в стандартах ГОСТ 19.503 «Единая система программной документации. Руководство системного программиста. Требования к содержанию и оформлению» и ГОСТ 19.504 «Единая система программной документации. Руководство программиста. Требования к содержанию и оформлению», но согласно РД 50-34.698 и общим положениям по написанию программной документации и общим требованиям к программным документам (ГОСТ 19.001 и ГОСТ 19.105), разработчик имеет право по собственному усмотрению определять его содержание, вводить новые разделы и исключать излишние разделы.

«Руководство администратора» - обобщенное название группы документов, регламентирующих деятельность эксплуатационного персонала по обеспечению целостности программного обеспечения АС и ее базы данных, а также по поддержанию требуемого уровня информационной безопасности. В зависимости от масштабности системы, количества и сложности ее функций административный персонал АС может иметь различную структуру (единственный администратор; несколько сменных администраторов с одинаковыми полномочиями; главный (системный) администратор с подчиненными ему сменными администраторами и т. п.). В системах со сложной и непрерывно актуализируемой базой данных могут предусматриваться должности администраторов информационной базы и/или контент-менеджеров, в системах с открытым доступом (интернет-конференции, форумы, аукционы и т. и.) - должности модераторов и т. д. Каждая категория эксплуатационного персонала наделяется определенными полномочиями по управлению программными и информационными ресурсами автоматизированной системы, а также обязанностями по поддержке эффективной деятельности пользователей и оказанию им необходимых консультаций. Права и обязанности каждой выделенной категории эксплуатационного персонала АС, а также доступные соответствующим работникам системные инструменты и ресурсы определяются в отдельных руководствах. Поскольку в большинстве автоматизированных систем административные полномочия являются вертикально интегрированными (полномочия администраторов нижнего уровня доступны администратору более высокого уровня), то такая же интеграция должна быть характерна и для эксплуатационных документов.

Как правило, в «Руководстве администратора» представляется информация:

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

■ описанию рабочих мест пользователей ЛС;

■ описанию пользователей АС и управлению их полномочиями;

■ обеспечению информационной безопасности АС;

■ мониторингу состояния АС;

■ выполнению профилактических процедур, необходимых для поддержания работоспособности ЛС;

■ описанию наиболее вероятных аварийных ситуаций и методики их ликвидации;

■ описанию диагностических процедур, предназначенных для проверки работоспособности ЛС, и рекомендаций по устранению выявленных проблем;

■ описанию сообщений АС и рекомендаций по их интерпретации.

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

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

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

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

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

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

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

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

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

«Описание применения» - документ, содержащий наиболее общее и доступное описание функций, состава и возможностей автоматизированной системы²⁷. Приводимый в нем материал позволяет ознакомиться со структурой системы, ее назначением, характеристиками, взаимосвязями с другими АС. Этот документ может использоваться для первоначального изучения АС - например, новым пользователем или потенциальным клиентом, рассматривающим возможность ее приобретения.

Документ «Описание применения» может иметь следующую структуру:

1. Назначение системы. Указывается вид деятельности, для автоматизации которой предназначена система. Перечисляются объекты автоматизации (подразделения, рабочие места и т. п.), на которых используется АС, а также реализуемые системой функции. Описывается распределение автоматизированных функций по объектам автоматизации.

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

3. Описание взаимосвязей АС с другими системами. Перечисляются автоматизированные системы, с которыми взаимодействует рассматриваемая АС. Указываются внешние объекты, являющиеся поставщиками входной и/или потребителями выходной информации. Описываются виды, характер и регламент межсистемных и внешних связей.

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

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

3 Информационное обеспечение САПР

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

- о материалах и комплектующих изделиях;

- о типовых проектных решениях;

- о состоянии текущих разработок;

- о нормативно-справочной проектной документации.

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

Литература:

1. Полубедов В.С., Ткачев Е.А. Проектирование автоматизированных систем обработки и управления. Часть 1. – Серпухов: ИПК СВИ РВ, 2001. - 126 с.

2. Норенков И.П. Основы автоматизированного проектирования: Учеб. для вузов. 2-е изд. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. – 336 с.

3. Оценка характеристик сложных автоматизированных систем./А.С. Шаракшанэ, А.К. Халецкий, И.А. Морозов. – М.: Машиностроение, 1993.-272 с.

Дата добавления: 2014-10-17; просмотров: 707; Нарушение авторских прав

Мы поможем в написании ваших работ!