Основы метрологии, стандартизации и сертификации (стр. 6 )

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

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

Рис.7.2. Сценарий решения системы линейных уравнений

Логическое проектирование

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

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

Таблица 7.1

Описание студентов

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

Таблица 7.2

Описание специальностей

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

Аналогично опишем другие объекты, используемые в нашей программе:

Таблица 7.3

Описание предметов (дисциплин)

Таблица 7.4

Список групп

Таблица 7.5

Список преподавателей

Тот факт, что студент Иванов поступил в институт в 2001 году на специальность ПВС, можно записать в таблицу:

Таблица 7.6

Таблица соответствия «Студент-специальность-год поступления»

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

Рис. 7.3. Логическая модель данных

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

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

Оценка полноты логической модели данных и структуры программных модулей

Последним шагом разработки общей структуры программы является проверка ее правильности. Рассмотрим перечень выделенных нами программных модулей. (Напоминаю, мы их еще не программировали, а просто сказали, что такие модули должны быть в нашей программе и выполнять указанные действия). Проверим, хватит ли нам этого набора модулей для реализации всех задач, поставленных перед программой. Для этого попробуем построить решение каждой из задач программы в виде последовательности работы программных модулей. Это напоминает детский конструктор. Хватит ли у нас деталек нужной конфигурации, чтобы собрать задуманное? Отличие только в том, что один и тот же модуль можно использовать многократно, в нескольких задачах[8]. Если все задачи могут быть представлены таким образом, наш набор достаточно полный и мы можем двигаться дальше.

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

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

Формирование конкретных требований к программным модулям

«Обратная волна» требований

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

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

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

Проиллюстрируем способ описания требований к программным модулям на примере одного из модулей решения системы линейных уравнений (см. рис.7.3).

Описание программного модуля

Название модуля: Ввод коэффициентов уравнений

Назначение: Ввести коэффициенты и свободные члены решаемой системы линейных уравнений, Проверить полноту и корректность введенных данных

Форма вызова: Gauss_Input(n)

Входные параметры: Размерность системы уравнений (n)

Требования: целое число от 1 до 100

Источник информации: пользователь. Достоверность обеспечивается пользователем

Выходные (возвращаемые параметры): Коэффициенты и свободные члены системы уравнений

Требования:

1) значения – числа

2) количество коэффициентов в каждом уравнении равно размерности системы

3) для каждого уравнения указывается свободный член

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

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

n<20 . Ввод данных в таблицу, полностью умещающуюся на экране. Вызывается экранная форма с n+1 столбцами и n строками. Названия столбцов: X1, X2 …Xn,b. Если в любую ячейку вводится нечисловое значение, появляется сообщение: «Введите число!». Кнопка «ОК» активизируется только тогда, когда все ячейки таблицы заполнены числами..

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

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

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

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

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

Хотелось бы Вам жить в таком доме?

Проектирование интерфейса программы

Система меню

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

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

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

Экранные формы

Контекстная подсказка

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

Что это такое (терминологические вопросы) Для чего это нужно (методические вопросы) Как это сделать (технические вопросы)

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

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

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

К сожалению, довольно часто программисты «забывают» написать методическую и терминологическую части подсказок. Если программа достаточно сложная и использует нетривиальные методы, отсутствие этих подсказок приводит к непониманию и множеству недоразумений при ее использовании. Примером хороших контекстных подсказок являются Help’ы к MS Office.

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

Топик – раздел подсказки, посвященный одному вопросу. Топик имеет заголовок и идентификатор. Большинство современных средств программирования позволяют организовать контекстный вызов топика из определенного места программы (например, из окна).

Рабочий топик – посвящен техническим вопросам работы с конкретным окном программы.

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

1. Общие рекомендации:

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

1.2.  Терминологические топики небольшого размера, в тексте которых нет гиперссылок, удобно вызывать как всплывающее окошко (PopUp).

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

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

1.5.  При создании справки должен, по возможности, выдерживаться единый стиль. Цвета и размеры фона и шрифтов, оформление заголовков и гиперссылок, должны быть приятными и удобными для чтения. При выборе стиля желательно придерживаться фактического стандарта Windows. Различия в оформлении должны помогать пользователю ориентироваться в справочном файле. Например, рабочие, и методические топики могут отличаться каким-либо элементом стиля (цветом фона, формой заголовка или видом шрифта).

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

2.  Требования к рабочим топикам. Эти топики должны вызываться контекстно из каждого экрана программы. Основные требования к ним:

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

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

2.3.  Описание порядка работы. В рабочем топике должны присутствовать ответы на следующие вопросы:

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

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

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

2.3.4.  Что в результате происходит при работе с этим экраном. На какие экраны происходит переход с этого экрана, в каких случаях. Для интерпретации получаемых результатов делаются гиперссылки на соответствующие методические топики.

3.  Методические топики. Должны включать:

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

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

4.  Терминологические топики. Кроме определений и пояснений в глоссарий желательно включить схемы и рисунки, иллюстрирующие взаимосвязи основных понятий. Сами определения желательно снабдить гиперссылками вида: «См. также…», отсылающими пользователя к определениям понятий, связанных с данным. Ссылками на термины, помещенные в глоссарий желательно снабдить все случаи использования данного термина в справочной системе.

Советы молодому программисту

Как написать программу, понятную пользователю

1.  Если Вы хотите использовать программу в России, ее интерфейс должен быть написан по-русски.

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

3.  В названии экрана указывайте задачу, которую нужно решать с его помощью.

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

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6 7 8