2.5.2. Обеспечение точности перевода

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

• поймите задачу, поставленную заказчиком;

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

• выполните план, проверяя правильность каждого шага;

• проанализируйте полученное решение.

2.5.3. Преодоление барьера между пользователем и разработчиком

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

2.5.4. Контроль принимаемых решений

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

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

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

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

3. Архитектура программного средства

3.1. Понятие архитектуры программного средства

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

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

• Определение способов взаимодействия между выделенными программными подсистемами.

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

3.2. Основные классы архитектур программных средств

В работе [2] приводится следующая классификация архитектур программных средств:

• цельная программа;

• комплекс автономно выполняемых программ;

• слоистая программная система;

• комплекс параллельно выполняемых программ.

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

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

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

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

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

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

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

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

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

Нетрудно увидеть, как идеи, выдвинутые Дейкстра более 20 лет назад, воплотились в архитектуре операционных систем UNIX и последних версий Windows.

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

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