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

МИНИСТЕРСТВО ОБЩЕГО И ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

 

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ОРДЕНА ТРУДОВОГО КРАСНОГО ЗНАМЕНИ ИНСТИТУТ ТОЧНОЙ МЕХАНИКИ И ОПТИКИ (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

 
 

 


Б.С.Падун

 

Конспект лекций по дисциплине

"Технология разработки программного обеспечения"

 

специальность 2203: "Системы автоматизированного проектирования"

 

Санкт-Петербург

2000г.


 

СОДЕРЖАНИЕ

 

Введение ...............……….…………………………..……….……….… 3

В1. Цель и задачи курса ............…………………….……....…....... 3

В2. Роль программных систем САПР ТПП в современном

производстве ……………………………………………………. 3

В3. Развитие САПР ТПП ……………………………………..……. 4

В4. Связь курса с другими дисциплинами …....……..…………. 9

В5. Основные разделы курса …………………………………….. 9

Глава 1. Общие вопросы программного обеспечения САПР ТПП 9

Структура и состав программного обеспечения (ПО)

САПР ТПП ……………………………………………………

1.2. Назначение основных компонент ПО, связь с другими

видами обеспечения САПР ТПП …………………………..

1.3. Основные принципы проектирования ПО САПР ТПП

1.4. Методы разработки ПО САПР …………………………….

Глава 2. Классификация сфер применения и пользователей

САПР ТПП ……………………………………………………….

2.1. Характеристика сфер применения САПР ТПП ………….

Характер решаемых задач и квалификация

пользователей САПР ТПП …………………………………….

2.3. …………………………..

 

 

Глава 4. Качество программного обеспечения ……………………….

4.1. Анализ эффективности функционирования

программных систем …………………………………………...

4.2. Основные характеристики качества программных

систем …………………………………………………………….

4.3. Показатели качества этапа проектирования

программных систем …………………………………………...

4.4. Показатели качества этапа эксплуатации

программных систем …………………………………………...

4.5. Показатели качества этапа сопровождения

программных систем …………………………………………...

Глава 5. Вопросыразработки и внедрения пакетов прикладных

программ

5.1. Стадия исследования и обоснования создания САПР …..

5.2. Стадия технического задания ……………………………….

5.3. Стадия эскизного проекта ……………………………………

5.4. Стадия технического проекта ………………………………

5.5. Стадия рабочего проекта ……………………………………

5.6. Стадия изготовления несерийных компонент ……………

5.7. Стадия введения в действие комплекса средств

автоматизации проектирования …………………………….

5.8. Стадия сопровождение программных систем …………….

Глава 6. Основные требования, предъявляемые к программному

продукту со стороны пользователя ………………………..

 

Глава 8. Основы технологии разработки программного обеспечения ..

8.1. Понятие технологии программирования ……………………….

8.2. Модульное программирование ……………………………….

8.3. Программирование сверху-вниз …………………………………

8.4. Структурное программирование ………………………………

8.5. HIPO-технология ……………………………………

8.6. R-технология ………………………………………………………


ВВЕДЕНИЕ

В1. Цель и задачи курса

Данная дисциплина предназначена для подготовки студентов к созданию и эксплуатации автоматизированных систем ТПП (САПР ТПП). После изучения данной дисциплины студент должен: · знать принципы построения САПР ТПП и уметь применять их на практике;

В2. Роль программных систем САПР ТПП в современном производстве

· уменьшение затрат времени на цикл: идея построения новой машины или прибора -> выпуск новой машины или… · дефицит квалифицированной рабочей силы.

В3. Развитие САПР ТПП

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

В4. Связь курса с другими дисциплинами

В5. Основные разделы курса

Глава 1. Общие вопросы программного обеспечения САПР ТПП

Структура и состав программного обеспечения (ПО) САПР ТПП

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

Назначение основных компонент ПО

К общему ПО относятся операционная система, комплексы программ технического обслуживания, пакет прикладных программ, расширяющих возможности…

Основные принципы проектирования ПО САПР ТПП

Системы программного обеспечения ЭВМ открыты, что позволяет пополнять и корректировать их состав, не препятствуя этим развитию тех-      

Структура математического обеспечения АСТПП

• обеспечение технологичности конструкции изделий, включая структурный анализ изделий (какие детали и сборочные единицы входят в изделий),… • разработка технологических процессов, включая выбор заготовок, методов их…  

Рис. 5. Структура математического обеспечения АСТПП


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

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

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

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

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

Рассмотрим характеристики сферы применения ЭВМ, на основе чего определим характеристики пакета прикладного ПО АСТПП.

АСТПП предназначена для увеличения производительности труда инженерно-технического состава предприятия, занятых решением задач технологической подготовки производства (ТПП) и повышения качества решений задач ТПП за счет их оптимизации. Особую актуальность АСТПП имеют в условиях единичного и серийного производства, которые характеризуются высокой номенклатурой, допускаемых изделий и быстрой их сменяемостью. Количество предприятий с единичным и серийным характером производства в настоящее время составляет примерно 80-85% от всех предприятий на территории России. Номенклатура деталей, подлежащих изготовлению на таких предприятиях составляет 15-20 тыс. В месяц необходимо спроектировать от 4 до 16 тыс. деталей операций, которые, в свою очередь должны быть обеспечены всем необходимым технологическим оснащением.

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

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

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

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

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

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

Использование ЭВМ для проведения анализа производства позволит оценить большое число производственных ситуаций, которые определяют вид алгоритмов решения конкретных технологических задач. За счет этого увеличится достоверность проектируемых алгоритмов. Но даже в этом случае трудно ожидать, что будут учтены все производственные ситуации, а, следовательно, прослежены все варианты связей между входами и выходами алгоритмов или совокупностью алгоритмов. Поэтому высока вероятность появления ошибки, эти ошибки возможны при записи отдельных правил выбора решений, либо при определении состава признаков, которые должны быть учтены при решении задачи, либо при определении множества решений задачи и т. п. Проверку алгоритма на ограниченном числе деталей можно провести только после описания отладки программ, составленных по этим алгоритмам. Процесс отладки программ очень трудоемок и составляет 50-70% от всех работ по проектированию МО АСТПП. После длительной отладки программ часто оказывается, что алгоритм не работает на проверочных примерах. После этого алгоритм проектируется, а затем корректируется и повторно отлаживается программа, при этом часты случаи, когда незначительные изменения алгоритмов приводят к большим изменениям программы. Иногда возникают ситуации, когда легче написать программу заново, чем попытаться ее исправить. Такой цикл повторяется до тех пор, пока алгоритм и программа не будут отлажены на проверочных примерах.

Методы разработки ПО САПР

1) построение гипотезы о характере существующих связей между элементами объектов производства и решениями технологической задачи ( в соответствии с… 2) проверка гипотезы на контрольных примерах ( чаще всего гипотеза проверяется… 3) если связи построены неправильно, то они корректируются, то есть повторяется цикл, начиная с пункта 1.

Глава 2. Классификация сфер применения и пользователей САПР ТПП

2.1. Характеристика сфер примененияСАПР ТПП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Характер решаемых задач и квалификация пользователей САПР ТПП

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

A) Структуры пакетов прикладных программ

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

Лингвистическое обеспечение АСТПП

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

Глава 4. Качество программного обеспечения

Анализ эффективности функционирования программных систем

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

Основные характеристики качества программного обеспечения.

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

Рис.12. Схема жизненного цикла программных систем


 
 

 


Рис.13. Схема показателей качества программных систем


задач использования и целей анализа, от характера внешних условий и т.д. доминирующим становится один или несколько показателей.

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

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

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

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

4.3. Показатели качества этапа проектирования программных систем

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

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

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


Таблица 2.Вспомогательные показатели качества.

Этапы жизненного цикла
Проектирование Эксплуатация Сопровождение
1. Структурная упорядоченность программ и данных 1. Корректность постановки задач 1. Структурная упорядоченность ПС и данных
2. Степень стандартизации структуры модулей и переменных 2. Полнота и точность спецификаций 2. Степень стандартизации структуры модулей и переменных
3. Документированность ПС 3. Уровень языков программирования 3. Документированность для модификаций
4. Методическая обеспеченность технологии проектирования 4. Полнота тестирования программ 4. Уровень языков программирования
5. Степень комплексной автоматизации технологии проектирования 5. Степень помехозащищенности программ 5. Степень комплексной автоматизации технологии проектирования
6. Уровень языков спецификаций, программирования и отладки 6. Документированность для эксплуатации 6. Обеспеченность контроля изменений версий и распространения копий
7. Квалификация специалистов и методы организации работ    

 


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

Замечание: вследствие быстрого роста структурной сложности при увеличении числа условных вершин целесообразно ограничивать размер программных модулей.

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

(1)

где V – объем текста программы в битах; V* - потенциальный объем описания программ – это объем наиболее компактного текста программы для фиксированного алгоритма, написанного на языке самого высокого уровня.

Выражение (1) может быть представлено в виде

,

где l - показатель уровня языка используемой системы программирования (см. табл.4).

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

,

где S – интенсивность анализа и принятия решений программистом, измеряемая числом символов, которые различает программист в секунду (S≈18).

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


Таблица 3. Значения показателей сложности программных систем

  Показатель сложности Уровень сложности
простой средней сложности сложный сверх-сложный
1. Трудоемкость создания, чел. - годы 0,1 1-10 103-104
2. Длительность разработки, годы 0,1-0,5 1-2 2-5 3-10
3. Количество разрабатывающих специалистов, чел 1-2 3-10 10-100 100-1000
4. Длинна программы, операторов 103 104 105 106-107
5. Количество модулей, шт. 1-3 10-102 103 104-105
6. Количество обрабатываемых переменных, типов 102-103 104-105 106-108
7. Длительность решения варианта задачи, ч. 10-2-10-1 102-103
Допустимое время отклика, с. 106-104 103-102 10-0,1 10-2-10-4

 

Таблица 4. Значения показателя уровня языка l

Язык программирования Уровень языка l
PL-1 1,53
Алгол 1,21
Фортран 1,14
Ассемблер 0,88

 


 

 


Рис.14. Виды сложности проектирования.

 

 

                               
 
               
 
 
 
 
 

 


Рис.15. Пример графа программы (а) и полного множества маршрутов в этом графе (б)


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

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

где М – множество индексов модулей ПС; - переменная, учитывающая связь i-го модуля с j-ым; - переменная, учитывающая связь j-го модуля с i-ым; и могут принимать либо значения 1, если связь есть, либо 0, если связи нет.

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

Полное количество информационных связей в ПС равно:

где G – множество индексов информационных единиц (переменные, которые передаются в модуль как формальные параметры, также являются информационными единицами); - переменная, учитывающая использование k-ой информационной единице в i-ом модуле; - переменная, учитывающая формирование k-ой инфор-мационной единице в i-ом модуле:

 
 
 
 

 

 


Управляющие и информационные связи, описываются матрицами связей.

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

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

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

• корректность текстов программ, синтаксическая и семантическая. Корректность текстов определяется степенью соответствия исходных программ формализованным правилам этих языков. Многие некорректности этих типов выявляются автоматически в процессе трансляции исходных текстов программ;

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

• корректность данных структурная и функциональная (иначе, корректность значений). Структурная корректность данных определяется правилами их структурирования и упорядочивания. Эти правила могут быть достаточно полно формализованы без учета конкретных особенностей функционирования программ. Функциональная корректность данных связана в основном с конкретизацией их содержания в процессе исполнения программ, а так же при подготовке данных;

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

Метрики корректности программных модулей весьма разнообразны и довольно полно представлены в [8].

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

Показатели качества этапа эксплуатации программных систем

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

Показатели качества этапа сопровождения программных систем

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

Глава 5. Разработка и внедрение пакетов прикладных программ

Создание САПР осуществляется по следующим стадиям (ГОСТ 24.601-86 « Автоматические системы. Стадии создания »):

• исследование и обоснование создания САПР;

• техническое задание;

• эскизный проект;

• технический проект;

• рабочая документация;

• изготовление несерийных компонентов комплекса средств автоматизации проектирования;

• ввод в действие.

Стадия исследования и обоснования создания САПР

Выделяют два этапа: • обследование предприятия; • разработка требований к системе.

Стадия технического задания

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

Выделяют следующие этапы:

• научно–исследовательские работы;

• разработка аванпроекта;

• разработка ТЗ на САПР в целом и при необходимости частных ТЗ на подсистемы САПР.

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

Разработка аванпроекта выполняется для выбора рационального варианта САПР и предварительной проработки структуры создаваемой системы.

ТЗ является исходным документом для создания САПР и обязательным документом при приемке САПР. ТЗ должно содержать следующие разделы:

• наименование и область применения;

• основание для создания;

• характеристика объекта проектирования (назначение, состав, условия применения);

• цель и назначение (критерии эффективности функционирования);

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

• требования к САПР в целом и к отдельным подсистемам;

• технико-экономические показатели

• стадии и этапы;

• порядок испытаний и ввод в действие;

• источники разработки и финансирования.

Допускается вводить и другие разделы, поясняющие концепцию и проведение работ по созданию САПР.

По результатам работ на каждом этапе формируется отчет. При оформлении ТЗ используют РД 50-459-84 «САПР. Типовое техническое задание на создание систем».

Стадия эскизного проекта

Выделяют следующие этапы: • предварительная проработка процесса автоматизированного проектирования; • принятие основных решений по структуре САПР и взаимодействие САПР с другими системами;

Стадия технического проекта

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

Стадия рабочего проекта

Выделяют следующие этапы: • разработка рабочей документации на САПР; • разработка или адаптация программ;

Стадия изготовления несерийных компонент

Выделяют следующие этапы: • изготовление компонентов КСАП; • автономная отладка и испытание компонентов КСАП;

Стадия введения в действие комплекса средств автоматизации проектирования

Выделяют следующие этапы: • проведение опытного функционирования САПР; • проведение приемочных испытаний;

Стадия сопровождение программных систем

 


Глава 6. Основные требования, предъявляемые к программному продукту со стороны пользователя

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

Покупатель оценивает стоимость программной системы и трудоемкость ее освоения ( Т ):

3 = С + к Т,

где к – стоимость норма-часа специалиста, который осваивает программный продукт.

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

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

Например,

1) Текст – процессоры имеют в своем составе команду GLOBAL FORMAT, с помощью которой форматируют текст. При ее применении текст форматируется со вставленными в него таблицами. Таблицы, после применения такой команды превращаются в нечто, что не читается и практически не восстанавливается;

2) электронные таблицы (Spread Sheets): LOTOS 1-2-3, SUPERCALC, QUATTRO PRO, EXCEL, которые предоставляют программисту самые широкие возможности при создании продукта, которые передаются пользователю. Пользователь вынужден работать со всем инструментарием, который предоставляется и программисту. И это богатство возможностей часто играет с неквалифицированным пользователем скверную шутку. Например, при использовании команд типа: SORT или ARRANGE работа пользователя будет безнадежно испорчена. При этом, подобные команды выполняются электронной таблицей без лишних расспросов, к тому же, команда ARRANGE в меню стоит первой.

Недопустимо, чтобы продукт, явно ориентированный на пользователя, предъявлял к нему такие требования, которые затруднят и многих программистов. А также очень нежелательно, чтобы пользователю надо было бы освоить большое число команд (например, в редакторе их “всего” от 44 до 300 и более). В электронных таблицах, например, используется восьмиуровневое иерархическое меню, каждый уровень содержит до 20 команд, а общее их сочетание достигает 15 тыс.. Что делать пользователю (а также и программисту), если изрядная часть этих 15 тыс. команд приводит к фатальным последствиям?

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

Допустимость для пользователя программного продукта заключается в том, чтобы продукт НЕ потребовал от него.

1) высокого интеллекта;

2) тренированной памяти;

3) интеллектуальных усилий;

4) полного самоконтроля;

5) напряженного внимания;

6) трудолюбия и полной самоотдачи;

7) интенсивной работы с клавиатурой или мышью.

Идея с позиций доступности – это вирусы и игровые программы, которые имеют широкое и долговременное распространение. Их отличают простота, так как для конфигурирования и управления используется обычно весьма ограниченный набор клавиш (чаще всего “стрелки“ (ARROWS) и ENTER, либо SPACE) .Расположение командных клавиш таково, что и забывчивый и неловкий пользователь не испытывает затруднений и редко промахивается, причем даже промах не приводит к фатальным последствиям . Прочие клавишные команды (если они есть) не являются обязательными.

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

1) ввести данные неправильного типа или формата;

2) ввести данные не туда;

3) забыть сохранить файл данных;

4) сохранить файл данных так, что потом система его не найдет;

5) потерять, испортить, стереть файл;

6) дать неправильную команду (их просто не существует);

7) задать неверный режим;

8) потерять результаты;

9) получить результаты, непригодные для использования;

10) «подвесить» программу и многое, многое другое.

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

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

Рассмотрим некоторые положения этой технологии:

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

2) Идеальный случай – программный продукт не содержит управляющих клавиш. Активны лишь алфавитно–цифровые клавиши, клавиши управления курсором, клавиша ENTER

3) Идеальный случай - программный продукт не содержит управляющих команд (никаких F10, CTRL+B, ALT+X, ESC). Управление вводом-выводом осуществляет сама программа с помощью встроенного в него Анализатора экрана.

В основу Анализатора экрана положен факт, что в каждый заданный момент ввода редактирование вывода состояния экрана и всей задачи уникально. Следовательно, не так трудно отследить момент, когда нужно произвести какие-либо действия и эмулировать необходимую команду без участия пользователя. В качестве критерия можно использовать, например, текущее положение курсора или заполненность определенного поля. Можно применять и менее очевидные критерии, например, состояние и содержание буферов и стеков. В сложных программных системах Анализатор контролирует содержимое экрана или программы до 18 раз в секунду и отслеживает одновременно до 50 различных состояний. Соответственно, в любой момент (но не одновременно) могут быть выполнены до 50 различных команд без какого-либо участия пользователя.

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

4) Диалог должен быть типа “Короткий вопрос - Короткий ответ” (SQSA). Например, если по мнению Анализатора, ввод исходных данных завершен, то на экране будет выведен следующий вопрос:

 
 

 


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

Вопрос должен быть предельно коротким и ясным, а из возможных ответов допустимы лишь ДА и НЕТ. Максимально возможное число выводимых подряд оконных микроменю не более трех. Программа, задающая свыше трех вопросов подряд, вызывает у пользователя раздражение.

5) Следует иметь только одно (главное) меню. Причем оно должно содержать 5-6 пунктов и быть одноуровневым. Если же после выбора пункта меню у программной системы останутся вопросы, то их можно уточнить позднее, в форме «Кратких вопросов» (SQSA). Оптимальным считается простейшее вертикальное меню типа NORTON, распложенное в центре экрана на нейтральном фоне. Меню не должно содержать функций удаления чего бы то не было. Удаление файлов, баз данных и так далее может производиться пользователем только после выхода из программной системы средствами MS-DOS.

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

Если программная система предусматривает выбор и загрузку одного из ранее созданных пользователем файлов, не желательно приводить в меню одни только их имена. К имени файла весьма уместен комментарий (приблизительно на 40-50 символов). Комментарий извлекается из какого-либо поля файла данных. Полезна также датировка.

Например,

 

G_KOLON Деталь изделия ПМГ-10 12.05.92
G_RUCH Деталь изделия Д-700 05.07.92
G_BAL Деталь изделия ПМГ-10 01.11.12

 

Если пользователь не задает имени файла, то его присваивает система со специальными символами. Например, ## DDMMYY, где DD.MM.YY- показания системного таймера, а ## - порядковый номер сеанса или файла, созданного в указанный день. В этом случае меню выбора для пользователя выглядит так:

 

Сеанс 07 от 25 июня 1992 года
Сеанс 01 от 29 июня 1992 года

При выходе из системы файл должен быть сохранен автоматически.

7) Ввод данных должен проводиться по «по бумажному», т.е. экран полностью, до деталей, копирует знакомый пользователю бланк или документ. Следует стараться организовать экран так, чтобы в любой момент работы у пользователя не возникала необходимость произвести сложный скроллинг экрана. Иначе говоря, для ввода или получения справки он должен пользоваться только стрелками ”←“, ”→”, “↑”, “↓”.

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

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

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

Следует отслеживать поля - антагонисты (если они есть) или коррелирование поля. Комплементарные поля (взаимодействующие поля как ключ-замок) должны заполняться оба или оба не задаваться.

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

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

8) Вывод результатов должен состоять из нескольких этапов. Первоначально они должны выводиться на экран (без всяких команд) для просмотра. Вывод результата также следует оформить «по-бумажному». Затем должна выводиться документация на печать в форме , которая не требует дополнительного редактирования.

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

Когда просмотр результата, по мнению Анализатора, закончен, то на экране можно вывести вопрос :

 
 

 


В случае НЕТ просмотр продолжается либо следует окончить сеанс. По окончании печати документов полезно повторить запрос, поскольку документы печатаются в нескольких экземплярах:

 
 

 

 


Результирующие файлы должны быть сохранены на диске, не ожидая указаний пользователя.

В программах вывода необходимо предусматривать все возможные сбои периферийного устройства вывода (типа PAGER OUT). Они не должны приводить к сбоям или зависаниям программной системы.


Технология создания программного продукта.

 

7) Виды памяти, модель внешней памяти, организация обмена данными между оперативной и внешней памятью.

8) Функции, принципы и способы построения ПО САПР и реализации в них типовых алгоритмов проектирования.

9) Этапы жизненного цикла программ.


10) Особенности технологии программирования сложных программных комплексов.

Система группирования деталей.

Постановка задачи. Пусть задано множество деталей D, каждая деталь d Î D описывается n признаками d = (mi1, mi2,…,min). Необходимо разбить… Для решения задачи необходимо определить пространство признаков, в котором… Подсистема определения признакового пространства предназначена для анализа существующих групп деталей и формирования…

Основы технологии разработки программного обеспечения

Понятие технологии программирования

Что явилось причиной создавшейся ситуации? До некоторого момента времени программирование считалось и, что вполне естественно, складывалась как… Начиная с 1970 года в нашей стране и за рубежом для уменьшения стоимости… Следовательно, технология программирования – это методы программирования, направленные на совершенствование…

Модульное программирование

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

Программирование сверху-вниз

1) Начать программирование почти одновременно и параллельно с разработкой алгоритмов; 2) Формально, в виде программы некоторой гипотетической машины, фиксировать… 3) Легко модифицировать программу по уровням, путем замены одной гипотетической машины на другую;

Структурное программирование

В структурном программировании любой алгоритм на любом уровне проектиро-вания, организованного по нисходящей схеме, должен быть записан только с… В конструкции выбора Р(х) – это одномерный предикат вида Р(х)=(х*А), где * -…             (х*А) (х*В) ……. (х*С) …

Б-стилизованные рекурсивные диаграммы

Для суперпозиции допустимых структур, не требуется применение операторов GOTO поэтому, структурное программирование называется еще программированием… Теоретическая основа структурного программирования, допускает реализацию его… 8.5. HIPO – технология

Система МТ (метатранслятор)

• с проблемно-ориентированных языков; • с непроцедурных языков ППП; • с информационных языков;

Рис. 11. Состав метатранслятора


Система МТ допускает реализацию произвольного контекстно-свободного языка. Контекстные условия могут быть заданы на мета семантическом языке на основе контекстно свободного описания.

Ограничения:

1) длина не терминала в правилах в правилах синтаксиса языка не должна превышать 80 символов;

2) количество элементов словаря синтаксиса языка не должно превышать 600;

3) число правил синтаксиса не должно превышать 2000;

4) допускается использование не более 10 выводных файлов.

Примеры применения системы МТ.

I. Обеспечение диалогового режима работы.

1) манипуляция диалоговыми данными; 2) средства вывода диалоговых данных на экран дисплея в виде таблиц и набора… 3) база данных.

II. Обращение к вычислительной системе в графической форме

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

III. Описание внешних схем баз данных

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

IV. Входной язык пакета прикладных программ

Язык СИДЕКОН позволяет задавать описание способа дискритизации, информацию о граничных условиях, физико-механических свойствах материала, внешних… Результатом трансляци программына СИДЕКОНе является программа на ФОРТРАНЕ. СИДЕКОН предназначен для инженеров-проектировщиков, которые используют КОМБИК.

Рис.14. Описание фрагмента чертежа как внешней схемы базы данных


Пример оформления алгоритма расчета режимов резания