Структурная схема использования комплекса программ. Структурная схема программы

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

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

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

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

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

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

Фрагменты с горизонтальными вызовами на одном уровне мо­гут быть преобразованы в вертикальные вызовы модулей разных уровней посредством введения дополнительных переменных, кото­рые не могли быть получены декомпозицией функционального описания на подфункции. Эти дополнительные переменные обыч­но имеют тип целый или логический и называются флагами, сема­форами, ключами событий. Их смысл обычно характеризуется фра­зой: в зависимости от следующей предыстории действий, выпол­нить такие-то действия.

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

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

Флаг - переменная, значение которой свидетельствует о том, что некоторый аппаратный или программный компонент находится в определенном состоянии или что для него выполняется опреде­ленное условие. Флаг используется для реализации условного ветвления и прочих процессов принятия решений.

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

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

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

В этом методе разбиение сложной системы на несколько подсистем получило название «разделяй и властвуй » (divide et impera), иерархическая или функциональная декомпозиция и др. При этом базовыми принципами являются:

a) «разделяй и властвуй»;

b) Проектирование «сверху вниз» - от общей постановки задачи к отдельным подзадачам и т.д.;

c) принцип иерархического упорядочения, который предполагает объединение составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

Структурная схема разрабатываемого программного обеспечения

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

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

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

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

Рис. 4.1. Пример структурной схемы программного комплекса.

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

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

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

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

Функциональная схема или схема данных (ГОСТ 19. 701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения этих схем используют специальные обозначения, установленные стандартом.

Функциональные схемы более информативны, чем структурные. На рис. 4.4 для сравнения приведены функциональные схемы программных комплексов и систем.

б)

Рис. 4.4. Примеры функциональных схем: а - комплекс программ, б - программная система.

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

Структурное проектирование использует три основных вида моделей (диаграмм):

1) SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы;

2) DFD (Data Flow Diagrams) - диаграммы потоков данных;

3) ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь».

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

Главным компонентом модели является диаграмма . На ней все функции и интерфейсы представлены в виде блоков и дуг соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху . Входная информация, которая подвергается обработке, показана с левой стороны блока, а результат (выход) - с правой . Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 4.5).

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

Рис. 4.6

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

Основными компонентами диаграмм потоков данных являются:

a) внешние сущности;

b) системы и подсистемы;

c) процессы;

d) накопители данных;

e) поток данных.

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

Подсистема (см. рис. 4.8) или процесс (рис. 4.9) представляются прямоугольником с закругленными краями. Он содержит три поля:

a) Номера;

c) Физической реализации.

Подсистема и процесс отличаются именем. В первой записывается название подсистемы, а во втором – глагол, определяющий, что делает процесс.

Рис. 4.8. ГНИ – Государственная налоговая инспекция

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

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

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

Более сложная диаграмма потоков данных приведена на рис. 4.12.

ER-диаграммы будут рассмотрены позднее.

В курсовом проекте, кроме функциональной диаграммы, необходимо представить схемы алгоритмов наиболее сложных функций (например, сортировки и поиска).

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

Разработка структуры программного обеспечения

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

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

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

модуль личного кабинета;

Модуль отображения расписания предназначен для приема от пользователя информации о запрашиваемом расписании и выводе его на дисплей или на печать.

Полная структурная схема проектируемого программного обеспечения представлена на рисунке 2.1.

Рисунок 2.1 - Структурная схема программного обеспечения

Детальное рассмотрение каждого модуля позволяет ее представить в виде следующих элементов:

«Ввод параметров запроса» - позволяет указывать данные для запроса.

«Отображение страницы расписания» - формирование страницы с запрошенными данными на экране.

«Формирование электронных документов» - формирование файлов с запрошенными данными.

«Отправка расписания» - отправка при изменениях, данных с изменениями.

Разработка функциональной схемы

Функциональная схема или схема данных (ГОСТ 19.701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом.

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

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

модуль отображения расписания;

модуль личного кабинета;

Функциональная схема программного обеспечения общего вида представлена на рисунке 2.2.

Рисунок 2.2 - Функциональная схема программного обеспечения

Информация, которой будет оперировать информационная система, организована в виде базы данных, созданной средствами MySQL (рисунок 16).

Рисунок 16 Схема базы данных, созданной средствами MySQL

Формализация расчетов (алгоритмы расчета и решения задач)

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

При расчёте стоимости установки натяжного потолка необходимо заполнить форму «Стоимость», которая содержит 3 поля да ввода данных: ширина потолка, длина потолка, фактура материала. После заполнения данных полей программа запрашивает из базы данных MySQL, данные о стоимости материала с данной фактурой. Стоимость рассчитывается путём умножения площади потолочного покрытия на стоимость материала за 1 м 2 .

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

Структурная схема использования комплекса программ (дерево диалога)

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

Разработанное приложение имеет интуитивно понятное меню. Для работы с таблицами базы данных модуля ИС «Управление предприятием» состоит из.

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

Рис.2 Схема взаимодействия и сязей данных

Разработка функциональной схемы программы.

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

Примерный перечень функций системы.

1) Регистрация обменной операции

· Ввод данных по покупке валюты

· Ввод данных по продаже валюты

· Ввод данных по конверсии валюты

· Печать справки клиента

2) Просмотр документов

· Просмотр списка документов дня

· Просмотр списка архивных документов

3) Ведение справочников

· Ввод данных по кодам ценностей

· Ввод данных по видам документов

· Ввод данных по кодам валют

· Ввод курсов валют по датам

4) Генерация отчетных документов

· Печать реестра наличной иностранной валюты, купленной за наличные рубли;

· Печать реестра наличной иностранной валюты, проданной за наличные рубли;

· Печать реестра по обмену (конверсии) наличной иностранной валюты;

5) Прочие функции

· Ввод данных в поле ввода из справочника

· Перевод числа из цифровой формы в строчную (сумма прописью)

· Изменение вида курсора

· Сохранение данных в архивных файлах

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

Разработка структурной схемы программы.

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

Разработка экранного интерфейса программы

Существующие подходы к проектированию экранного интерфейса

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

Наиболее практичными и удобными с точки зрения пользователя можно считать системы, имеющие экранный интерфейс, построенный на основе системы всплывающих меню. Наиболее распространенными в настоящее время являются две идеологии (имеются в виду DOS-приложения), включающие в себя и определенную форму экранных окон и цветовую гамму и вид всплывающих списков. Это инструментальные Среды фирмы Borland, и операционная оболочка Norton, фирмы Symantec. Обе идеологии предусматривают определенное разбиение экранного пространства на области или зоны, предназначенные для конкретных информационных объектов и действий. Зоны могут быть в некоторой степени переконфигурированы по желанию пользователя: изменены размеры и положение на экране. Команды обработки данных вызываются из системы меню, присутствующего на экране постоянно (Borland), или вызываемого по функциональной клавише (Symantec).

И в том и в другом случае все команды системы распределены по функциональному признаку на группы и в главном меню присутствуют

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

Таким образом, создается система многоуровневого всплывающего меню. Применение такой идеологии обеспечивает удобство ориентировки в системе, имеющей достаточно сложное, многоуровневое меню с множеством выборов. Естественно, что увеличение вложенности и размеров списков выбора, должно иметь разумные границы, которые к счастью имеются в виде ограниченности экранного пространства монитора. В большинстве систем заложена также возможность настройки цветовой палитры по желанию пользователя. В операционной оболочке Norton предлагается выбор гаммы из нескольких стандартных вариантов, в системах фирмы Borland можно создать свою собственную цветовую гамму, вплоть до мельчайших деталей. Примерный вид некоторых экранных объектов приведен на рис.4,5.

Выбор идеологии экранного интерфейса