2. Каноническое проектирование информационных систем

Стадии и этапы процесса проектирования системы

Идея деления процесса проектирования на стадии и этапы состоит в том, чтобы постепенно, проектируя «сверху вниз», разрабатывать проектные решения сначала укрупненно, а потом детализированно.

Процесс проектирования рекомендуется проводить в соответствии с ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» [6], действие которого продлено до настоящего времени (Указатель Государственных стандартов 2003 г.).

Указанный ГОСТ предлагает следующие 8 стадий процесса проектирования информационной системы:

1). Формирование требований к автоматизированной системе.

2). Разработка концепции автоматизированной системы.

3). Техническое задание.

4). Эскизный проект.

5). Технический проект.

6). Рабочая документация.

7). Ввод в действие.

8). Сопровождение автоматизированной системы.

Имеется возможность установить состав стадий и этапов в зависимости от сложности объекта автоматизации, поскольку этот документ носит рекомендательный характер.

Заметим, что этап — это часть стадии. В каноническом проектировании используется каскадная или итерационная модели создания информационной системы (рис. 2.1). Итерационная модель – это каскадная модель с промежуточным контролем. Ошибки или недоработки предыдущих стадий, обнаруженные на последующих стадиях, устраняются путем возврата к предыдущим стадиям, то есть итерационным путем.

Рис. 2.1. Итерационная модель проектирования информационной системы

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

Можно выделить три укрупненные стадии проектирования информационной системы:

- Предпроектную, включающую стадии 1, 2, 3.

- Проектную стадию, включающую стадии 4, 5,6.

- Послепроектную стадию, включающую стадии 7,8.

Рассмотрим состав и содержание работ на этих стадиях.

Состав работ на предпроектных стадиях

Стадия 1. Формирование требований к автоматизированной системе

Главное на этой стадии – провести предпроектное обследование и дать технико-экономическое обоснование целесообразности создания системы. Формируются требования к функциональной части, обеспечивающим подсистемам, методу проектирования.

Стадия 2. Разработка концепции автоматизированной системы.

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

Стадия 3. Техническое задание.

Техническое задание – итог предпроектной работы по созданию информационной системы. Это документ, обращенный к Исполнителю. Главным здесь является состав функциональных задач будущей системы и требования к обеспечивающим подсистемам. Этот документ формируется по материалам первых двух стадий и состовляется в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».

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

Стадия 4. Эскизный проект

Выполняется применительно к информационной системы в экономике редко. Цель – разработка предварительных решений.

Стадия 5. Технический проект.

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

Стадия 6. Рабочая документация.

Эта стадия иногда называется рабочим проектом. Главное назначение: программирование или адаптация готовых программных средств. Кроме того, здесь составляются технологические инструкции, которые соответствуют должностным инструкциям, уточненным на стадии технического проектирования. В должностных инструкциях указывается, что нужно сделать, а в технологических – как это сделать.

При наличии прототипа системы стадии технического проекта и рабочей документации объединяются в одну проектную стадию.

Состав работ на стадиях ввода в действие и сопровождения информационной системы

Стадия 7. Ввод в действие

Осуществляется проведение опытной эксплуатации и сдача системы комиссии в постоянную эксплуатацию в соответствии с требованиями технического задания (ТЗ).

Стадия 8. Сопровождение автоматизированной системы

Цель сопровождения системы – поддержание эксплуатационных характеристик на проектном уровне. Сопровождение осуществляется Исполнителем (консультативная помощь, устранение недостатков, разработка предложений по развитию системы).

Обследование информационной системы

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

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

В соответствии с поставленной целью задачами обследования являются:

1). Установление состава функциональных задач в базовом варианте, их краткое содержательное описание и требования к периодичности, оперативности и достоверности обработки информации по задачам.

2). Установление информационной взаимосвязи задач.

3). Определение документооборота между подразделениями.

4). Описание документов (наименование, объем информации, периодичность и трудоемкость составления, связь с задачами и подразделениями).

5). Описание показателей (наименование, состав реквизитов, связь с документами).

6). Описание реквизитов (наименование, их содержательный смысл, система кодирования).

7). Описание базы данных (состав, структура, объем файлов).

8). Установление структуры управленческих работ подразделений (виды работ и их удельный вес).

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

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

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

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

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

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

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

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

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

Карточка учета документа составляется для каждой формы документа и содержит:

наименование документа;

- объем информации;

- периодичность составления;

- трудоемкость составления;

- подразделение, в котором формируется документ;

- код наименования документа.

Код наименования документа состоит из кода подразделения, в котором формируется документ, и порядкового номера документа внутри подразделения.

Карточка учета показателя содержит:

- наименование показателя;

- реквизитный состав;

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

- код наименования показателя.

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

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

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

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

- графовые информационные модели;

- матричные информационные модели;

- информационно-технологические схемы;

- операционные таблицы;

- CASE-модели.

Реализация обследования предполагает наличие методики проведения обследования, которая включает в себя:

- программу проведения обследования;

- объекты обследования;

- степень детализации анализа;

- методы и формы сбора данных;

- правила обработки результатов на ПК.

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

Описание постановки задачи

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

Согласно ГОСТ, задача (Problem) – часть автоматизированной функции управления, характеризуемая конечным результатом в конкретной форме.

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

Описание постановки задачи предусматривает:

- содержательное описание задачи в словесной форме (экономическая сущность задачи, цели, эффективность, периодичность решения задачи, достоверность, оперативность, связь с другими экономическими задачами);

- составление информационно-технологических схем с выделением этапов решения;

- описание входной информации (первичные документы и файлы баз данных);

- описание выходной информации (отчеты, справки);

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

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

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

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

Структура описания постановки задачи представлена на рис. 2.2.

!!!!!!!!!!!!!!!!!!!!!

Рис. 2.2. Структура описания постановки задачи

Состав, содержание и принципы организации информационного обеспечения информационной системы

Структура типовых компонент информационного обеспечения информационной системы представлено на рис. 2.3.

Организация информационного обеспечения предусматривает его разделение на внемашинное и внутримашинное.

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

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

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

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

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

- условно-постоянную информацию;

- переменную информацию.

Эта классификация количественно характеризуется коэффициентом стабильности информации:

 ,

где   — объем файла;   — объем корректуры к файлу за год.

Если   > 0.75, то файл считается условно-постоянным.

По содержанию, к условно-постоянной информации относится в основном нормативная и справочная информация.

К переменной относится информация оперативного учета. Файлы условно-постоянной информации должны быть сформированы до начала работы системы. А файлы переменной информации формируются во время ее работы.

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

- конструкторские нормы (состав изделий, применяемость);

- технологические нормы (технологические маршруты, нормы расхода материала на деталь, трудоемкость деталеопераций, станкоемкость деталеопераций);

- данные бухгалтерского учета основных средств;

- ценники;

- справочники наименований.

Файлы переменной информации:

- данные оперативного учета (в натуральной форме);

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

- прочие файлы.

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

Рекомендуется выбор метода распределения информации согласно следующим качественным характеристикам (табл. 2.1). Более точный выбор метода распределения требует вариантных количественных расчетов.

Таблица 2.1 Выбор метода распределения информации

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

Таблица 2.2 Реквизитный состав файла

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

- однократность ввода информации;

- минимизация дублирования информации;

- возможность наращивания состава функциональных задач без переструктурирования базы данных (инвариантность);

- многопользовательский режим запросов;

- масштабируемость;

- информационная безопасность;

- резервирование информации.

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

Слово кодирование происходит от латинского «codex» (свод законов).

Система кодирования – совокупность знаков и правил их использования для представления информации.

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

Рассмотрим кодирование реквизитов-признаков. Задача состоит в том, чтобы закодировать элементы производственного процесса: предметы и результаты труда, средства труда и сам труд.

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

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

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

Существуют следующие системы кодирования:

1). Порядковая. Объекты кодируются числами натурального ряда. Используется для кодирования небольших и устойчивых номенклатур объектов. Например, код семейного положения: единица означает холост, двойка – женат, тройка – разведен, четверка – вдовец.

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

3). Повторений. По этой системе код представляет собой повторение какого-либо количественного признака объекта. Например, год 2005 может быть закодирован как 05.

4). Классификационная. Система основана на классификации объектов кодирования и записи в разрядах кодового обозначения значений признаков классификации. Различают две системы классификации объектов кодирования:

- последовательную (иерархическую),

- параллельную (фасетную).

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

Рис. 2.4 Схема последовательной классификации

 α - признак классификации, в примере имеющий два значения: α1 и α2.

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

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

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

Рассмотрим примеры смешанных систем кодирования:

Перечислим требования к системе кодирования:

1). Однозначное соответствие между кодом и объектом.

2). Семантичность, необходимая для алгоритмов машинной обработки.

3). Постоянная длина кода для всех обозначений (равномерность), поскольку поля в памяти имеют постоянную длину для реквизитов данного наименования.

4). Наличие резерва в разрядности кода для кодирования новых объектов.

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

6). Возможность легкого запоминания кодов человеком-оператором.

7). Возможность обнаружения и исправления ошибок.

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

С целью глобализации и стандартизации систем классификации и кодирования информации создана единая система классификации и кодирования (ЕСКК).

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

Проектирование системы документации

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

Очевидна целесообразность унификации системы документации в допустимых пределах. Унификация систем документации может быть на разном уровне управления: межотраслевом, отраслевом и уровне предприятия (локальные системы документации).

На межотраслевом уровне в настоящее время разработан целый ряд унифицированных систем документации (УСД), к которым относятся:

- единая система конструкторской документации (ЕСКД);

- единая система технологической документации (ЕСТД);

- унифицированная система форм статистической отчетности;

- унифицированная система документов бухгалтерского учета и отчетности и др.

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

Рассмотрим проектирование форм первичных документов.

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

По содержанию документы для машинной обработки обычно видоизменяются по сравнению с документами для ручной обработки:

- в документе должен быть минимально необходимый состав показателей;

- следует устранить неоправданное дублирование одних и тех же показателей в различных документах;

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

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

- в документ вводятся новые реквизиты: кодовые обозначения, контрольные суммы и т.д.

Каждый документ включает в себя: заголовок, предметную часть и основание. Заголовок содержит данные, относящиеся ко всему документу: наименование, код формы, номер, дату. Основание – это подпись и печать. В предметной части заключается основное содержание документа.

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

Анкетная форма – это последовательность вопросов и ответов.

Пример – личная карточка (рис. 2.7).

Вопрос – это наименование реквизита.

Ответ – это значение реквизита и кодовое обозначение. Кодовые обозначения, которые предстоит вводить в машину, выделяются утолщенными линиями.

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

Зональная форма предусматривает выделение в документе отдельных зон, в которых располагаются логически взаимосвязанные реквизиты.

Табличная форма является наиболее компактной. Наименования реквизитов стоят во главе столбцов, а значения – находятся в графо-клетках.

Пример – номенклатура-ценник материалов (рис. 2.9).

Существуют комбинированные формы представления предметной части.

После составления проекта документа необходимо его согласовать с пользователем. Рекомендуется оставлять на бланке документа место для примечаний. Размеры графо-клеток должны соответствовать обозначениям реквизитов (с учетом машинного заполнения). А сам размер бланка документа должен быть стандартным.

Проектирование пользовательского интерфейса

Пользовательский интерфейс или человеко-машинный диалог - это набор приемов взаимодействия с компьютером. Грамотно построенный интерфейс сокращает число ошибок и способствует тому, что пользователь чувствует себя с системой комфортнее. От этого, в конечном итоге, зависит производительность работы – основной показатель качества пользовательского интерфейса.

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

- дизайн интерфейса должен отвечать правилам эргономики;

- естественность (интуитивность) работы с программой;

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

- стандартность приёмов работы (согласованность с прошлым навыком);

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

- интерактивная помощь (возможность ее вызова из любого места программы);

- очевидность меню (простая формулировка, иерархическая структура, логическое соответствие пунктов и подпунктов);

- действия пользователя должны быть обратимыми (то есть должна представляться возможность отмены (undo));

- возможность использования «горячих» клавиш; экстренный выход из программы.

Проектирование человеко-машинного диалога начинается с выбора диалогового языка.

Классификация диалоговых языков представлена на рис. 2.10.

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

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

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

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

В перспективе предусматривается распространение интерфейса, включающего в себя речевые команды - SlLK-интерфейса (Spich-Речь, Image-Образ, Language-Язык, Knowledge-Знание).

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

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

Основные компоненты пользовательского интерфейса – это то, что пользователь видит на экране.

Рассмотрим проектирование основных компонентов пользовательского интерфейса, к которым относятся: меню, экранные формы и отчеты.

Проектирование иерархического меню

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

- проектирование содержания меню;

- проектирование формы меню;

- программное обеспечение меню.

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

Выбор пункта меню может завершаться:

- появлением на экране меню нижнего уровня;

- выполнением команды (например, возвратом в системное меню);

- выполнением процедуры (например, процедуры ввода или вывода информации, функциональной обработки);

- появлением «заглушки» — сообщения о том, что данный пункт еще не реализован, или же другого комментария.

В главном меню следует предусмотреть пункт «ВЫХОД», который позволяет вернуться к системному меню, что удобно при отладке системы.

Рассмотрим вопросы проектирования формы меню.

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

Существует ряд правил, которыми следует руководствоваться при проектировании меню. Эти правила соответствуют международным стандартам по проектированию пользовательского интерфейса. Один из этих стандартов — CUA (Common User Access).

Назовем следующие рекомендации;

1). Количество уровней в меню должно быть не более 2-3.

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

3). Пункты меню не нумеруются.

4). Название пунктов горизонтального меню должно быть коротким — из одного слова.

5). Заглавной должна быть только первая буква названия пункта.

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

Для выбора пункта всплывающего меню может быть предназначена «горячая» клавиша (hot key), поскольку путь к нему через главное меню может быть долгим.

Пункты, к которым часто обращаются, должны быть расположены в начале меню. Если присутствует пункт «Помощь», то он располагается в начале главного меню, а пункт «Выход» — в конце.

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

При формировании меню может быть выбрана цветовая схема (color scheme). Вертикальное (всплывающее) меню может быть выделено тенью (shadow).

Проектирование экранных форм

Экранные формы в настоящее время образуют основу интерфейса в человеко-машинном диалоге.

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

- проектирование содержания экранной формы;

- проектирование ее формы представления (формы экрана);

- программное обеспечение экранной формы.

Содержание экранной формы зависит от ее назначения. По назначению можно выделить четыре класса экранных форм:

- для ввода информации в базу данных, то есть для формирования и ведения базы данных;

- для ввода параметров обработки информации по задаче и идентификаторов запросов (условия выборки);

- для вывода результатов решения задачи (отчётов) и справочной информации;

- комбинированные экранные формы, предусматривающие многоцелевое назначение (диалоговые окна).

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

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

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

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

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

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

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

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

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

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

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

Зона сообщений содержит подсказки и сообщения об ошибках. Обычно она занимает нижнюю строку экрана.

Проектирование отчетов

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

Проектирование отчетов (машинограмм) состоит из следующих этапов:

1). Проектирование содержания отчета;

2). Проектирование формы отчета;

3). Программное обеспечение формирования отчета.

Рассмотрим первый этап (Проектирование содержания отчета) .

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

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

Основное содержание отчета составляют реквизиты файлов базы данных.

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

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

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

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

Перейдем к проектированию формы отчета (Второй этап).

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

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

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

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

Современные СУБД (Access, Oracle, MS SQL Server и др.) содержат средства автоматизации проектирования меню, экранных форм и отчетов. Эти средства направлены на упрощение проектирования формы, а также автоматизируют программное обеспечение указанных компонентов пользовательского интерфейса.

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

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

Проектирование фактографических баз данных

Распределение работ по стадиям канонического проектирования фактографической базы данных показано на рис. 2.11.

!!!!!

Итоговая задача предпроектной стадии – разработка инфологической модели предметной области без привязки к конкретной СУБД.

Основой конкретной инфологической модели является модель «сущность-связь» (Entity-Relationship – ER-модель), описывающая взаимосвязь объектов (сущностей) предметной области.

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

!!!!!!!!!!

Рис. 2.11. Распределение работ по стадиям проектирования фактографической базы данных

При ручном методе проектирования базы данных строится графическое изображение структуры базы данных.

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

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

На стадии рабочего проектирования осуществляется настройка выбранной СУБД и подготовка технологических инструкций для первоначального формирования и последующего ведения базы данных.

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

Методы автоматизированного проектирования базы данных предусматривают использование CASE-средств.

Так, CASE-средство Silverrun американской фирмы Silverrun Technologies, Inc. содержит модуль концептуального (инфологического) моделирования данных (ERX-Entity Relationship Expert), который обеспечивает построение моделей данных «сущность-связь», не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать инфологическую модель данных посредством ответов специалистов в данной предметной области на вопросы о взаимосвязи данных. Результаты работы этого модуля передаются в модуль реляционного моделирования (RDM – Relational Data Modeler) для проектирования даталогической реляционной модели данных.

Проектирование документальных баз данных

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

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

Завершается стадия утверждением технического проекта (ТП).

Рабочее проектирование состоит в формировании базы данных документов на основе ретроспективного анализа, их индексировании и формировании на этой основе базы данных ПОД.

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

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

!!!!!!

Рис. 2.12. Распределение работ по стадиям проектирования документальной базы данных