
- •Лекция №2. Основы стандартизации создания асу.
- •2. Васильев в.М. И др. Управление в строительстве. Учебник для вузов. М., асв. 1994.
- •3. Гинзбург в.М. Проектирование информационных систем в строительстве. Информационное обеспечение. Учебное пособие. М., асв, 2008.
- •5. Дикман л.Г. Организация строительного производства. Учебник для вузов. М., асв, 2003.
- •13. Синенко с.А., Гинзбург в.М. И др. Автоматизация организационно-технологического проектирования в строительстве. Учебное пособие м., асв, 2002.
- •1. Сапр – сложная (большая) система.
- •2. Обслуживающие подсистемы.
- •3. Проектирующие подсистемы
- •5. Задачи анализа и синтеза. Локальная оптимизация. Принятие решения.
- •6. Обеспечивающие подсистемы (виды обеспечения).
- •7. Организационно-техническое (технологическое) проектирование.
- •8. Организационно-технологические задачи функционирования
- •Лекция №2 Основы стандартизации создания асу
- •1. Стандарты.
- •2. Стандарты на проектирование.
- •3. Сапр в строительстве.
- •Гост 19. Единая система программной документации (еспд).
- •Лекция №3
- •1. Общие положения
- •2. Состав и содержание
- •Лекция №4 гост 24. Система технической документации на асу
- •1. Состав комплекса стандартов
- •Лекция №5
- •Гост 24.602-86 Единая система стандартов автоматизированных систем управления.
- •Автоматизированные системы управления.
- •Состав и содержание работ по стадиям создания
- •Лекция №6
- •Единая система стандартов автоматизированных систем
- •Управления
- •Автоматизированные системы управления Общие требования гост 24.104-85
- •Виды и состав обеспечения асу (сапр) Лекция №7 Функциональное обеспечение
- •Логико-информационная модель
- •Фрагмент логико-информационной модели.
- •Логико-информационная модель взаимосвязанных задач.
- •Лекция №8 Математическое обеспечение (мо)
- •Лекция №9 Информационное обеспечение
- •Перечень выходных документов, видиограмм и массивов
- •Описание входных документов, видиограмм и массивов
- •Перечень выходных документов, видиограмм и массивов
- •Описание выходных документов, видиограмм и массивов
- •Описание массива базы данных (имя файла)
- •Организация разработчик
- •Классификация и кодирование инфориации
- •Разработка диалога «пользователь – машина»
- •Форматы диалога
- •Пример:
- •Период времени Комплекс работ Вид работ Вывод
- •Входное сообщение
- •Выходное сообщение
- •Лекция №15 гост 34. Единая система программной документации (еспд).
- •Состав еспд
- •Лекция №16 Программное обеспечение
- •1. Организация программирования
- •2. Операционная система
- •3. Выбор языка программирования
- •4. Процесс программирования
- •В. Способ хранения данных, с которыми работает система
- •5. Отладка программ
- •Лекция №17 Блок-схема алгоритма
- •Лекция №18 Комплексная отладка программ на контрольных примерах
- •Лекция №19 Техническое обеспечение.
- •Лекция №20 Организационное обеспечение
- •Лекция №21 Методическое обеспечение
- •Лекция №22 Правовое обеспечение
- •Лекция №23 Эксплуатационная документация
Классификация и кодирование инфориации
(Смотри лекции в отдельном учебно-методическом материале)
Лекция №10
Классификация информации
Лекция №11
Кодирование информации.
Базы данных словарей информации
Лекция №12
Общероссийские системы кодирования информации
Лекция №13
Системное и локальное кодирование информации
Индексация строительных машин
Лекция №14
Лингвистическое обеспечение
Лингвистическое обеспечение АСУ должно быть достаточным для общения различных категорий пользователей в удобной для них форме со средствами автоматизации АСУ и для осуществления процедур преобразования и машинного представления обрабатываемой в АСУ информации.
В лингвистическом обеспечении АСУ должны быть:
предусмотрены языковые средства для описания любой используемой в АСУ информации;
унифицированы используемые языковые средства;
стандартизированы описания однотипных элементов информации и записи синтаксических конструкций;
обеспечены удобство, однозначность и устойчивость общения пользователей со средствами автоматизации АСУ;
разработаны терминологические словари;.
предусмотрены средства исправления ошибок, возникающих при общении пользователей с техническими средствами АСУ.
Лингвистическое обеспечение АСУ должно быть отражено в документации (инструкциях, описаниях) организационного обеспечения АСУ в виде правил общения пользователей с техническими средствами АСУ во всех режимах функционирования системы.
Разработка диалога «пользователь – машина»
Проектирование диалога
Создание внемашинного информационного обеспечения автоматизированных систем проектирования и управления проектированием включает разработку диалога между Пользователем пакетов программ и собственно ЭВМ. Специалист по разработке автоматизированных систем должен предложить специалисту в некоторой прикладной области (инженеру–строителю, архитектору, технологу и пр.) такую процедуру взаимодействия с ЭВМ, в процессе которой, общаясь на привычном ему профессиональном языке, ими совместно будет решена важная задача проектирования.
Под диалогом мы будем понимать взаимодействие, или интерактивный обмен сообщениями, между Пользователем и вычислительной системой для решения конкретной задачи. Автоматизированная система, предусматривающая в процессе своей работы использование такого диалога, носит название диалоговой системы.
Любая диалоговая система предполагает участие двух субъектов – активного участника, или инициатора диалога, которым обычно является человек, и собеседника – пассивного участника, роль которого отводится ЭВМ. Диалог разворачивается постепенно, по шагам. Шаг диалога заключается в подготовке и выдаче сообщения одним участником диалога (действия) и последующей подготовки и выдачи сообщения другим участником диалога (ответа). В этом случае, активный участник - Пользователь - должен иметь возможность выполнить некоторое действие, т.е. ввести в ЭВМ данные о принятом им решении, а ЭВМ, произведя соответствующие вычисления или обнаружив необходимую информацию в базе данных, сообщить Пользователю ответ. Этим создаются необходимые условия для принятия нового решения и выполнения соответствующего действия активным участником диалога, т.е. перехода к новому шагу диалога. Реализация каждого шага требует написания соответствующих машинных программ, как для выдачи на экран условий ввода и вывода сообщений, так и подготовки данных для ответа ЭВМ на выданную Пользователем команду.
Таким образом, можно считать, что проектирование автоматизированной системы является разработкой диалоговой последовательности или некоторого числа шагов диалога, в результате которых формируется результат решения задачи.
Целью разработки диалоговой последовательности является решение функциональной задачи Пользователя при условии обеспечения т.н. чувства интеллектуального удобства. Система является удобной для Пользователя, если его интеллектуальные усилия для понимания действий системы и выработки реакции на эти действия минимальны.
Можно перечислить основные критерии эффективности диалога Пользователь – ЭВМ, обеспечивающие чувство «удобства» при работе в системе.
Ясность диалога – возможность составления в сознании Пользователя непротиворечивой модели хода решения задачи ЭВМ. Пользователю должен быть в процессе диалога предоставлен хорошо структурированный список всех функций, выполняемых системой. Поведение системы должно быть предсказуемо и не может давать неожиданных эффектов (например, по-разному оформлять информацию в одинаковых ситуациях).
Гибкость диалога – возможность выбора альтернативных решений. Поведение системы должно учитывать разнообразие состояния Пользователя. Работа системы должна определяться целями, стоящими перед Пользователем. Так при решении одной и той же алгоритмической задачи, Пользователь может проводить новый расчет, т.е. пользоваться новым набором данных, или может решать новый вариант ранее решаемой задачи, изменяя часть информации, может использовать имеющееся готовое решение в качестве эталона для решения новой задачи того же класса. Таким образом, диалог будет в каждом случае требовать наличия каких-либо особенностей и вариантов переходов. На каждом шаге диалога Пользователь должен иметь, по крайней мере, два варианта выбора. Часто при различных целях, поставленных перед Пользователем, могут быть предложены различные форматы диалога.
Легкость обращения к системе – простота ввода в систему команд и возможность получать помощь от ЭВМ в сложных ситуациях. Система легкого общения должна обладать широким набором функций оказания помощи. Помощь, т.е. разъяснение возникшей ситуации или объяснение назначения следующего шага диалога, должна предоставляться как в общих, так и в специфических ситуациях. Хорошая система никогда не оставляет Пользователя наедине с его проблемами. Организация диалога должна быть близка правилам человеческого общения. Система не должна провоцировать Пользователя к необдуманным действиям. Она должна реагировать на ошибки Пользователя, его забывчивость и прочее. Защита от ошибок Пользователя должна предусматривать диагностику ошибок и четкое сообщение о них Пользователю, предоставление простых процедур исправления ошибок (так действия по исправлению ошибок должны быть связаны только с ошибочной информацией, а не со всем набором данных). Система должна уберечь Пользователя от уничтожения данных.
Продолжительность реакции ЭВМ в процессе диалога – относительно доступное для Пользователя время получение ответа в процессе реализации шага диалога.
Простота обучения – невысокие затраты времени для обучения работе с пакетом программ. Хорошие результаты обучения Пользователя достигаются, если руководство по работе с системой может быть предложено непосредственно на терминале. В случае, если необходима дополнительная помощь при обучении или вводное обучение должна быть подготовлена такая техническая документация (инструкция по эксплуатации), которая обеспечит ознакомление Пользователя со специфической информацией. В состав предметов обучения должны входить описания особенностей и средств системы, работа с терминалом, пути исправления ошибок.
Надежность – отсутствие сбоев и защита информации. В понятие надежности также входят такие свойства, как постоянная готовность системы к работе (доступность), предоставление помощи для обеспечения корректной работы системы.
Приведенный перечень критериев, естественно, противоречив, как обычно при построении многокритериальной системы. Так является обычно противоречивым одновременное выполнение требование гибкости и ясности диалога, т.к. при выборе из множества альтернативных решений тяжело сформировать ясную модель функционирования системы. Необходимо при проектировании диалога выбрать важнейшие для конкретного Пользователя критерии и оптимизировать эффективность работы с ЭВМ.
Разработка диалоговой системы включает два этапа: проектирование и программная реализация.
Под проектированием диалога обычно понимают проектирование сценария диалога, т.е. описание последовательности обмена сообщениями между Пользователем и Системой. Такое описание можно представить, как описание шагов диалога. Сценарий описывается в виде графа, в котором шаги диалога – узлы, а дуги – направление перехода.
При организации диалога можно выделить четыре его функции:
организация диалога (помогает Пользователю организовать сеанс общения через терминал);
управление диалогом (позволяет Пользователю управлять последовательностью выполнения этапов решения задачи);
Рис. Условные обозначения для изображения функций диалога
(1 – функция организации, 2 – функция управления, 3 – функция ввода-вывода, 4 – функция помощи).
ввод – вывод (применяется к доступным средствам ввода-вывода информации, прежде всего к терминалу вычислительной системы, позволяет осуществлять ввод исходных данных, их редактирование, просмотр, а также вывод печатного протокола решения задачи);
функция помощи (помогает в затруднительных ситуациях получать общую или специальную информацию о системе или о ходе решения задачи).
На рис. изображены условные обозначения для изображения указанных функций на графе диалога.
Пример графа сценария диалога приведен на рис.
Рис. Граф сценария диалога.
Цифрой «0» на рисунке обозначен корень графа, которым является головное меню с перечнем возможных альтернатив развития сценария решения задачи (1,2). Анализ направления дуг функций управления показывает, что из последовательности шагов каждой альтернативы можно вернуться в головное меню для выбора другой альтернативы развития решения задачи. Только функция 3 имеет одно направление развития. Эта функция завершает решение задачи (работы системы) и осуществляет выход в операционную систему. Функции организации 4,5,6 и 7 осуществляют шаги общения пользователя с системой по ходу решения задачи. Функции 8, 9 и 10 обеспечивают ввод и вывод информации (например, 8 – функция ввода, а 9 и 10 – функции вывода данных). С функцией 6 связана функция помощи.
Как видно из рассмотренного выше примера, на каждом шаге диалог определяется тремя компонентами: инициатором, возможностью выбора действия и представлением Пользователя о реакции ЭВМ на выбор им варианта продолжения работы Системы.
Рис. Граф сценария диалога задачи «Выбор монтажного крана»
На рис. рассмотрен граф сценария диалога для работы с системой, осуществляющей решение задачи «Выбор монтажного крана». Цифрами в окружностях – узлах графа – предусматривается реализация следующих функций организации диалога:
0 - Головное меню (корень графа).
1 - Проведение расчета.
2 - Поддержание базы данных «Монтажные краны».
3 - Конец работы.
11 - Ввод исходных данных.
111 - Ввод параметров монтируемых сооружений.
112 - Ввод параметров строительных конструкций.
12 - Расчет.
121 - Выбор рационального варианта.
1211 – Вывод результатов расчета.
21 - Ввод.
211 - Ввод параметров монтажного крана.
22 - Просмотр.
23 - Удаление.