Cтраница 2
Диалоговое программирование позволяет посредством экономно организованного диалога между участниками разработки свести задачу синтеза системы к последовательности задач анализа некоторой совокупности систем. При заданных характеристиках источника информации ( оракула) диалог считается рационально организованным, если идентификация задачи и вычисление решения требуемого качества проводятся наиболее экономным образом - при минимально возможном числе вопросов СПР ( математика) и ответов оракула. В диалоговом программировании решение наиболее сложной индивидуальной задачи, принадлежащей массовой задаче, обусловленной исходной априорной информацией, проводится за минимально возможное число элементарных актов диалога. [16]
Большая часть диспетчерских функций осуществляется е использованием программного прерывания. Типовые действия при обслуживании программного прерывания сводятся к запоминанию состояния основных регистров машины, обнаружению источника прерывания и идентификации запрашиваемой задачи. [17]
Описание / идентификация задач требует перечисления для каждой функции в каждом альтернативном варианте проекта всех последовательных действий ( задач), которые должны быть выполнены для реализации функции. Поскольку идентификация задач является оценочной ( т.е. связана с отбором вариантов), она довольно проста. Сама по себе идентификация задачи не оказывает реального влияния на проектирование. Возможность повлиять на проектирование появляется только тогда, когда задачу анализирует ИЧФ. [18]
Описание / идентификация задач требует перечисления для каждой функции в каждом альтернативном варианте проекта всех последовательных действий ( задач), которые должны быть выполнены для реализации функции. Поскольку идентификация задач является оценочной ( т.е. связана с отбором вариантов), OHJ довольно проста. Сама по себе идентификация задачи не оказывает реального влияния на проектирование. Возможность повлиять на проектирование появляется только тогда, когда задачу анализирует ИЧФ. [19]
К процессу разработки могут привлекаться и другие участники, группа экспертов с руководителем и др. Что касается формы взаимоотношения экспертов и инженеров, то применяются следующие формы: эксперт выполняет роль информирующего или учителя, а инженер роль ученика. Форма учитель-ученик больше соответствует реальности. В процессе идентификации задачи инженер и эксперт работают в тесном контакте. [20]
При реализации данной стратегии не требуются операции с заменителями, и поэтому должен быть порожден только экземпляр пакета Simple Port Def. Чтобы сократить число таких порождений экземпляров до минимума ( до одного), каждое сообщение, которое подразумевается на рис. 5.15, должно быть сформировано как экземпляр одного и того же типа данных. Кроме того, каждое сообщение должно нести идентификацию посылающей задачи, с тем чтобы ответ мог быть направлен обратно. Программисту не должно составить особого труда придерживаться двух этих ограничений. [21]
Описание / идентификация задач требует перечисления для каждой функции в каждом альтернативном варианте проекта всех последовательных действий ( задач), которые должны быть выполнены для реализации функции. Поскольку идентификация задач является оценочной ( т.е. связана с отбором вариантов), она довольно проста. Сама по себе идентификация задачи не оказывает реального влияния на проектирование. Возможность повлиять на проектирование появляется только тогда, когда задачу анализирует ИЧФ. [22]
Описание / идентификация задач требует перечисления для каждой функции в каждом альтернативном варианте проекта всех последовательных действий ( задач), которые должны быть выполнены для реализации функции. Поскольку идентификация задач является оценочной ( т.е. связана с отбором вариантов), OHJ довольно проста. Сама по себе идентификация задачи не оказывает реального влияния на проектирование. Возможность повлиять на проектирование появляется только тогда, когда задачу анализирует ИЧФ. [23]