Письмо 06 - Архитектура сложной системы
Многообразие средств разработки - Пример

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

Попробуем разработать для пользователей не программу, но инструмент, чтобы они самостоятельно могли создавать расчётные схемы. Допустим, что пока у нас нет детального представления о том, как вообще происходит начисление заработной платы ни для одной из категорий служащих и рабочих. Поэтому возьмём чистый лист бумаги и пойдём к тому эксперту-пользователю из отдела труда и заработной платы (ОТиЗ), который должен ввести нас в тонкости расчёта. На листе бумаги слева и справа проведём прямые вертикальные линии. Левая часть листа предназначена для списка той информации, которая должна поступать на вход расчётной схемы (входная информация). Правая часть листа отведена для списка видов начисления и удержания, которые получатся в результате расчёта (выходная информация). На средней части листа будет отрисована схема начисления заработной платы для конкретной категории служащих или рабочих. Попросим эксперта-пользователя заполнить левую и правую часть листа. Скорее всего, первоначально информация может оказаться неполной, но полной информации нам не требуется. Гораздо важнее понять, как формируются эти части информации.

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

Визуальное отражение расчётной схемы должно быть максимально простым, понятным и эргономичным. Здесь можно воспользоваться той же метафорой чистого листа бумаги, содержащего три зоны: зона входной информации, зона выходной информации и наборное поле в центре листа. Существует относительно небольшое количество элементов, с помощью которых пользователь может задавать суть и порядок расчётов. Прежде всего, к таким элементам относятся четыре арифметические операции (сложение, вычитание, умножение и деление) и вычисление процентов, а также определение различных коэффициентов (констант), используемых при расчёте. Помимо этого потребуется реализовать операцию выбора. Суть её состоит в том, что при известном входном значении должно формироваться одно выходное значение из допустимого множества. Эта операция является близким аналогом оператора «switch-case» в языке программирования Си. Возможно, в дальнейшем потребуются и иные операции, но в данный момент это не важно.

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

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

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

• повторное использование проверенного ранее кода;
• использование операции конструирования вместо кодирования.

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