Серверная часть системы

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

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

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

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

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

- повторяющиеся фрагменты программы можно объединить в один модуль;

- обычно программа делится на модули по принципу «Одна функция программы – один модуль», поэтому, если заказчик изменил в задании одну функцию, не надо модифицировать всю программу, достаточно доработать один соответствующий модуль;

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

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

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

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

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

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

Форма 1

Спецификация на модуль

1. Системное имя модуля.

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

3. Входные данные.

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

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

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

6. Способ вызова модуля (Имя вызывающего модуля, вызывающая команда, кнопка и т.д.).

7. Список вызываемых модулей.

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

Интерфейс пользователя

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

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

Технологическая часть.

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