Программное обеспечение управления автоматизированным комплексом многоканальной связи (стр. 10 из 16)

2.3.2 Структурный анализ

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

2.3.3 Структурное проектирование

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

2.3.4 Реализация и испытания

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

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

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

2.4 Вспомогательные средства проектирования

2.4.1 Графическая схема задания

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

Рис. 2.2. Графическая схема задания.

2.4.2 Развернутый план проекта системы

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

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

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

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

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

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

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

B. Программные средства. Указываются типы операционных систем, используемые библиотеки стандартных программ, системы управления базами данных.

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

III. Связь с внешней средой. Описывается взаимодействие пользователей с системой.

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

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

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

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

IV. Качество системы.

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

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

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

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

V. Документация по системе.

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

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

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

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

2.5 Организация процесса проектирования

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

· составление рабочих спецификаций

· составление перечня характеристик

· внешнее описание данных

· внешнее описание программ

· разработка архивов данных

· разработка программных модулей

· разработка тестовых задач

· кодирование программных модулей

· проверка программных модулей

· объединение программных модулей

· испытание системы в целом