В большей степени программные продукты не являются монолитом и имеют конструкцию (архитектуру) построения — состав и взаимосвязь программных модулей.
Модуль — это самостоятельная часть программы, имеющая определенное назначение и обеспечивающая заданные функции обработки автономно от других программных модулей.
Таким образом, программный продукт обладает внутренней организацией, или же внутренней структурой, образованной взаимосвязанными программными модулями. Это справедливо для сложных и многофункциональных программных продуктов, которые часто называются программными системами.
Структуризация программ выполняется в первую очередь для удобства разработки, программирования, отладки и внесения изменений в программный продукт. Как правило, программные комплексы большой алгоритмической сложности разрабатываются коллективом разработчиков (2 — 15 и более человек). Управлять разработкой программ в условиях применения промышленных технологий изготовления программ можно лишь на научной основе.
Блок-схемы для начинающих (Блок схемы алгоритмов)
Таким образом, структуризация программных продуктов преследует основные цели:
Структурное «разбиение» программ на отдельные составляющие служит основой и для выбора инструментальных средств их создания, хотя имеет место и обратное влияние — выбор инструментальных средств разработчика программного обеспечения определяет типы программных модулей. При создании программных продуктов выделяются многократно используемые модули, проводится их типизация и унификация, за счет чего сокращаются сроки и трудозатраты на разработку программного продукта в целом.
Некоторые программные продукты используют модули из готовых библиотек стандартных подпрограмм, процедур, функций, объектов, методов обработки данных.
На рис. 1.4 приведена типовая структура программного продукта, состоящего из отдельных программных модулей и библиотек процедур, встроенных функций, объектов и т.п.
Среди множества модулей различают:
В работе программного продукта активизируются необходимые программные модули. Управляющие модули задают последовательность вызова на выполнение очередною модуля. Информационная связь модулей обеспечивается за счет использования общей базы данных либо межмодульной передачи данных через переменные обмена.
Каждый модуль может оформляться как самостоятельно хранимый файл; для функционирования программного продукта необходимо наличие программных модулей в полном составе.
Структурно-сложные программные продукты разрабатываются как пакеты программ, и чаще всего они имеют прикладной характер — пакеты прикладных программ, или ППП.
ППП (application program package) — это система программ, предназначенных для решения задач определенного класса.
Компоненты ППП объединены общими данными (базой данных), информационно и функционально связаны между собой и обладают свойством системности, т.е. объединению программ присуще новое качество, которое отсутствует для отдельного компонента ППП. Структура ППП, как правило, многомодульная.
Структурная схема разрабатываемого программного обеспечения.
Структурной называют схему, отражающую состав и взаимодействие по управлению частей разрабатываемого программного обеспечения.
Структурные схемы пакетов программ не информативны, поскольку организация программ в пакеты не предусматривает передачи управления между ними. Поэтому структурные схемы разрабатывают для каждой программы пакета, а список программ пакета определяют, анализируя функции, указанные в техническом задании.
Самый простой вид программного обеспечения — программа, которая в качестве структурных компонентов может включать только подпрограммы ибиблиотеки ресурсов. Разработку структурной схемы программы обычно выполняют методом пошаговой детализации.Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов и т. п.Структурная схема программного комплекса демонстрирует передачу управления от программы-диспетчера соответствующей программе (рис. 5.1).
Рис. 5.1. Пример структурной схемы программного комплекса
Структурная схема программной системы, как правило, показывает наличие подсистем или других структурных компонентов. В отличие от программного комплекса отдельные части (подсистемы) программной системы интенсивно обмениваются данными между собой и, возможно, с основной программой. Структурная же схема программной системы этого обычно не показывает (рис. 5.2).
Рис. 5.2. Пример структурной схемы программной системы
Более полное представление о проектируемом программном обеспечении с точки зрения взаимодействия его компонентов между собой и с внешней средой дает функциональная схема.
Функциональная схема.Функциональная схема или схема данных (ГОСТ 19.701-90) — схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Основные обозначения схем данных по ГОСТ 19.701-90 приведены в табл. 5.1.
| Название блока | Обозначение | Назначение блока |
| Запоминаемые данные |  |
Для обозначения таблиц и других структур данных, которые должны быть сохранены без уточнения типа устройства |
| Оперативное запоминающее устройство |  |
Для обозначения таблиц и других структур данных, хранящихся в оперативной памяти |
| Запоминающее устройство с последовательной выборкой | 
|
Для обозначения таблиц и других структур данных, хранящихся на устройствах с последовательной выборкой (магнитной ленте и т.п.) |
| Запоминающее устройство с прямым доступом |  |
Для обозначения таблиц и других структур данных, хранящихся на устройствах с прямымдоступом (дисках) |
| Документ |  |
Для обозначения таблиц и других структур данных, выводимых на печатающее устройство |
| Ручной ввод |  |
Для обозначения ручного ввода данных с клавиатуры |
| Карта |  |
Для обозначения данных на магнитных или перфорированных картах |
| Дисплей |  |
Для обозначения данных, выводимых на дисплей компьютера |
Функциональные схемы более информативны, чем структурные. На рис. 5.3 для сравнения приведены функциональные схемы программных комплексов и систем.
Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок. К самым дорогим относятся ошибки, обнаруживаемые при комплексном тестировании, так как для их устранения могут потребоваться серьёзные изменения уже отлаженных текстов.
Рис. 5.3. Примеры функциональных схем: а — комплекс программ; б — программная система
Структурная схема программного продукта
Структурной называют схему, отражающую состав и взаимодействие по управлению частей разрабатываемого ПО.
Структурные схемы пакетов программ не информативны, поскольку организация программ в пакеты не предусматривает передачи управления между ними. Поэтому структурные схемы разрабатывают для каждой программы пакета.
Самый простой вид ПО – программа, которая в качестве структурных компонентов может включать подпрограммы (процедуры и функции).
Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов.
Структурная схема программного комплекса демонстрирует передачу управления от программы-диспетчера (гл.программы) соответствующей программе.
Рис. Пример структурной схемы программного комплекса
Структура программных продуктов
Чаще всего программные продукты имеют определенную конструкцию (архитектуру) построения – состав и взаимосвязь программных модулей, т.е. обладают внутренней организацией или внутренней структурой, образованной взаимосвязанными программными модулями.
Модуль – это самостоятельная часть программы, имеющая определенное назначение и обеспечивающая заданные функции обработки автономно от других программных модулей. Модуль состоит из логически взаимосвязанной совокупности функциональных элементов.
Структуризация программ выполняется в первую очередь для удобства разработки, программирования, отладки и внесения изменений в программный продукт. Структуризация программных продуктов преследует следующие цели:
- распределить работы по исполнителям, обеспечив приемлемую их загрузку и требуемые сроки разработки программных продуктов;
- построить календарные графики проектных работ и осуществлять их координацию в процессе создания программных изделий;
- контролировать трудозатраты и стоимость проектных работ и др.
Структурное разбиение программ на отдельные составляющие служит основой и для выбора инструментальных средств их создания, хотя имеет место и обратное влияние – выбор инструментальных средств разработчика ПО определяет типы программных модулей.
При создании программных продуктов выделяются многократно используемые модули, проводится их типизация и унификация, за счет чего сокращаются сроки и трудозатраты на разработку программного продукта в целом.
Некоторые программные продукты используют модули из готовых библиотек стандартных подпрограмм, процедур, функций, объектов, методов обработки данных.
Типовая структура программного продукта, состоящего из отдельных программных модулей и библиотек процедур, встроенных функций, объектов и т.п. приведена на рис. П1.1.
Среди множества модулей различают:
- головной модуль – управляет запуском программного продукта (существует в единственном числе);
- управляющий модуль – обеспечивает вызов других модулей на обработку;
- рабочие модули – выполняют функции обработки;
- сервисные модули и библиотеки, утилиты – реализуют обслуживающие функции.
В работе программного продукта активизируются необходимые программные модули. Управляющие модули задают последовательность вызова на выполнение очередного модуля. Информационная связь модулей обеспечивается за счет использования общей базы данных либо межмодульной передачи данных через переменные обмена.
Каждый модуль может оформляться как самостоятельно хранимый файл; для функционирования программного продукта необходимо наличие программных модулей в полном составе.
Структурно-сложные программные продукты разрабатываются как пакеты программ, и чаще всего они имеют прикладной характер – пакеты прикладных программ (ППП).
Большинство программных продуктов, особенно прикладного характера, ориентированных на конечного пользователя, работают в диалоговом режиме взаимодействия с пользователем таким образом, что ведется обмен сообщениями, влияющими на обработку данных.
В диалоговом режиме под воздействием пользователя осуществляются запуск функций (методов) обработки, изменение свойств объектов, производится настройка параметров выдачи информации на печать и т.п.
Многие программы помимо выполнения основных функций, должны обеспечивать поддержку диалоговых процессов. Они классифицируются на:
- программы с жестким сценарием диалога – стандартизированное представление информации обмена;
- дескрипторные программы – формат ключевых слов сообщений;
- тезаурусные программы – семантическая сеть дескрипторов, образующих словарь системы (аналог — гипертекстовые системы);
- программы с языком деловой прозы – представление сообщений на языке, естественном для профессионального пользования.
Наиболее просты для реализации и распространены диалоговые программы с жестким сценарием диалога, которые предоставлены в виде:
- меню – диалог инициируется программой; пользователю предлагается выбор альтернативы функций обработки из фиксированного перечня; предоставляемое меню может быть иерархическим и содержать вложенные подменю следующего уровня;
- действия запрос-ответ – фиксирован перечень возможных значений, выбираемых из списка, или ответы типа Да/Нет;
- запрос по формату – с помощью ключевых слов, фраз или путем заполнения экранной формы с регламентированным по составу и структуре набором реквизитов осуществляется подготовка сообщений.
Диалоговый процесс управляется согласно созданному сценарию, для которого определяются:
Для создания диалоговых процессов и интерфейса конечного пользователя наиболее подходят объектно-ориентированные инструментальные средства разработки программ.
Графический интерфейс пользователя (Graphics User Interface — GUI) является обязательным компонентом большинства современных программных продуктов, ориентированных на работу конечного пользователя. К графическому интерфейсу пользователя предъявляются высокие требования как с чисто инженерной, так и с художественной стороны разработки, при его разработке ориентируются на возможности человека.
Наиболее часто графический интерфейс реализуется в интерактивном режиме работы пользователя для программных продуктов, функционирующих в среде Windows, и строится в виде системы раскрывающихся меню с использованием в качестве средства манипуляции мыши и клавиатуры. Работа пользователя осуществляется с экранными формами, содержащими объекты управления, панели инструментов с пиктограммами режимов и команд обработки.
Стандартный графический интерфейс пользователя должен отвечать ряду требований:
- поддерживать информационную технологию работы пользователя с программным продуктом – содержать привычные и понятные пользователю пункты меню, соответствующие функциям обработки, расположенные в естественной последовательности использования;
- ориентироваться на конечного пользователя, который общается с программой на внешнем уровне взаимодействия;
- удовлетворять правилу «шести» — в одну линейку меню включать не более 6 понятий, каждое из которых содержит не более 6 опций;
- графические объекты сохраняют свое стандартизованное назначение и по возможности местоположение на экране.
Цели структурного программирования.
Целями структурного программирования являются:
1.Обеспечить дисциплину программирования в процессе создания программных комплексов. Дейкстра дал следующее определение: «Структурное программирование – это дисциплина, которую программист навязывает сам себе».
2.Улучшать читабельность программы. Читабельность улучшается, если придерживаться следующих правил:
- избегать использования языковых конструкций с неочевидной семантикой;
- стремиться к локализации действия управляющих конструкций и использования структур данных;
- разрабатывать программу так, чтобы ее можно было читать от начала до конца без управляющих
переходов на другую страницу.
3.Повышать эффективность программы. Этого можно достигнуть, если выполнять структурирование программы, разбивая ее на модули так, чтобы можно было легко находить и корректировать ошибки, а также чтобы текст любого модуля с целью увеличения эффективности можно было переделать независимо от других.
4.Повышать надежность программы. Этого можно достигнуть, если программа будет легко поддаваться сквозному тестированию и не создаст проблем для организации процесса отладки. Это обеспечивается хорошим структурированием программы при разбивке ее на модули и выполнением правил написания читабельных программ.
5.Уменьшать время и стоимость программной разработки. Это происходит в том случае, если каждый программист команды разработчиков становится способным писать и отлаживать большее количество программного кода, чем раньше, т.е. когда повышается производительность труда программиста. Соблюдение правил структурного программирования позволяет этого достигнуть.
Основные принципы структурной методологии
К основным принципам структурной методологии относятся:
1.Принцип абстракции. Абстракция позволяет программисту вообразить требуемое решение проблемы без сиюминутного учета множества деталей. Используя принцип абстракции, разработчик может рассматривать программу по уровням. Верхний уровень показывает большую абстракцию, упрощает взгляд на проект, в то время как нижний уровень показывает мелкие детали реализации.
2.Принцип формальности. Слово «формальность» предполагает строгий методический подход. Принцип формальности является базой для превращения программирования из импровизации в инженерную дисциплину. Кроме того, этот принцип дает основания для доказательства правильности программ, так как позволяет изучать программы (алгоритмы) как математические объекты.
3.Принцип «разделяй и властвуй». Данный принцип реализует подход к решению трудной проблемы путем ее разделения на множество мелких независимых подпроблем, которые легче понимать и решать.
При разработке ПО этот принцип означает разделение программы на отдельные фрагменты (модули), которые просты по управлению и допускают независимую отладку и тестирование.
4.Принцип иерархического упорядочения. Структура разбиения на части не менее важна, чем сам факт такого разделения. В применении к программированию этот принцип выдвигает требование иерархического структурирования взаимосвязей между модулями программного комплекса, что облегчает достижение рассмотренных выше целей структурного программирования.
Статьи к прочтению:
Презентация программного продукта. Конференция.
Похожие статьи:
Комплексная лабораторная работа по дисциплине ПКШ “Система классов улиц и домов” Руководство системного программиста (вид документа) писчая бумага (вид…
СОДЕРЖАНИЕ ВВЕДЕНИЕ. 2 1 ТЕОРЕТИЧЕСКАЯ ЧАСТЬ. 5 1.1 ОБЗОР СУЩЕСТВУЮЩИХ ПРОГРАММНЫХ ПРОДУКТОВ.. 5 1.1.1 ОБЗОР WINDOWS COMMANDER 5.11. 6 1.1.2 ОБЗОР FAR…
Источник: remnabor.net
Структурная схема программного продукта.
Все программы второго уровня выполняются канальным процессором и подразделяются на фоновые программы, программу — диспетчер фоновых программ и программы обработки прерываний.
На рис. 1 приведена упрощенная структурная схема организации этого программного обеспечения.
В следующих разделах приведены упрощенные структурные схемы фоновых программ, выполняющих функцию обеспечения правильной последовательности кадров. Эти схемы могут быть использованы при разработке программ независимо от языка программирования.
Фоновые программы в свою очередь на рисунке разделены на программы, обеспечивающие безошибочный обмен информационными кадрами (Пфо) и программы, выполняющие остальные функции канального уровня (Пфн). Все фоновые программы управляются диспетчером программ циклически и непрерывно.
Рис. 1. Структурная схема организации программного обеспечения безошибочного обмена информационными кадрами на канальном уровне сети Х.25
Программы прерываний выделены в программы обработки одного или нескольких байтов на передачу в канал (на физический уровень) или на прием из канала (с физического уровня). Механизм прерываний осуществляет прерывание работы текущей фоновой программы, переводит к работе программы прерывания. По завершению работы программы прерывания возобновляется выполнение прерванной фоновой программы.
Фоновые программы, которые не выполняют функцию управления потоком, на рисунке изображены в виде одного квадрата. К ним относятся функции установления и разъединения соединения, функции взаимодействия с сетевым уровнем сети Х.25 и другие функции.
Диспетчер программ (ДП) управляет последовательностью всех фоновых программ. Как видно из рисунка, все фоновые программы обеспечения правильной последовательности кадров разделены на программы передачи и программы приема.
Диспетчер программ запускает определенную фоновую программу, а после ее выполнения управление возвращается к диспетчеру с тем, чтобы он запустил другую фоновую программу.
Определение последовательности и частоты запуска программ является самостоятельной задачей оптимизации структуры программного обеспечения с точки зрения минимизации задержки обработки на приеме, потерь кадров и других качественных характеристик. Программы приема часто имеют приоритет перед программами передачи в службе передачи данных. В службе передачи речи или видео приоритет дается фоновым программам передачи. Это объясняется тем, что для обеспечения качества передачи данных важно не потерять пакет данных, а для качества передачи речи и видео важна величина задержки приема пакета при передаче.
Основной принцип работы большинства фоновых программ состоит в последовательной обработке блоков данных (кадров, пакетов и др.), находящихся в очередях на обслуживание программами. В случае конфигурации звена данных «точка-точка» образуются следующие очереди:
Оп32 – очередь пакетов на передачу с сетевого уровня на канальный уровень;
Оповт – очередь «I» (информационных) кадров на случай необходимости повторной передачи кадров в канал;
Окпм – очередь всех принятых кадров с канала (т.е, физического уровня), в которых при анализе КПК (контрольно-проверочной комбинации) не было обнаружено ошибок;
Оп23 – очередь пакетов, подлежащих передаче с канального уровня на сетевой уровень.
Приведем упрощенные структурные схемы основных фоновых программ передачи (P1ПД, P2ПД, P3ПД, P4ПД, P5ПД, P6ПД, P7ПД), приема (P1ПМ, P2ПМ, P3ПМ, P4ПМ) с кратким описанием их функционирования. Напомним, что фоновые программы запускаются диспетчером программ ДП. По завершению работы фоновая программа возвращает управление ДП.
Блок-схема алгоритма работы основных расчётных модулей.
Ниже приведен пример работы одного из модулей программы.
Источник: infopedia.su
Презентация на тему Разработка программного модуля для автоматизации работы менеджера автостоянки
Содержание ВВЕДЕНИЕ Анализ задания Сценарий диалога программы с пользователем Структурная схема Исходные данные Главная страница Страница «О проекте» Способ обработки ошибок Страница «Программа» Тестирование и откладка прикладного программного модуля ЗАКЛЮЧЕНИЕ
- Главная
- Информатика
- Разработка программного модуля для автоматизации работы менеджера автостоянки
Слайды и текст этой презентации
Слайд 1 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ИНСТИТУТ СФЕРЫ ОБСЛУЖИВАНИЯ
И ПРЕДПРИНИМАТЕЛЬСТВА (ФИЛИАЛ) ФЕДЕРАЛЬНОГО ГОСУДАРСТВЕННОГО БЮДЖЕТНОГО ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ ВЫСШЕГО
ОБРАЗОВАНИЯ «ДОНСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» В Г. ШАХТЫ РОСТОВСКОЙ ОБЛАСТИ (ИСОиП
(филиал) ДГТУ в г. Шахты Тема: «РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ ДЛЯ АВТОМАТИЗАЦИИ РАБОТЫ МЕНЕДЖЕРА «АВТОСТОЯНКИ»» по дисциплине Прикладное программирование Автор проекта ____________________________ Голубовский С.А. Специальность 09.02.03 Программирование в компьютерных системах Группа КВ9-316А Руководитель проекта ________________________ преподаватель И.А. Топоркова Шахты 2018
Слайд 2 Содержание
ВВЕДЕНИЕ
Анализ задания
Сценарий диалога программы с пользователем
Структурная схема
Исходные данные
Главная
страница
Страница «О проекте»
Способ обработки ошибок
Страница «Программа»
Тестирование и откладка прикладного
программного модуля
ЗАКЛЮЧЕНИЕ
Слайд 3 Введение
Данная работа посвящена разработке программного модуля «автоматизация работы
менеджера автостоянки». Эта задача имеет теоретическое и практическое значение
при разработке программных модулей программного обеспечения для компьютерных систем. Поэтому
тема проекта является актуальной.
Слайд 4 Анализ задания
Для выполнения поставленной задачи необходимо составить программный
модуль, отражающий данные о (регистрации клиента и поиске клиента
в базе).
Слайд 5 Сценарий диалога программы с пользователем
Диалог, реализованный в программе,
относится к типу меню ориентированных диалогов. Схема диалога представляет
собой общую конструкцию диалога, т.е. требуемую последовательность обмена данными между
пользователем и системой.
С помощью главной пользовательской формы осуществляется доступ к двум основным пунктам меню.
Слайд 6 Структурная схема
Результатом разработки структуры программного модуля является структурная
многоуровневая иерархическая схема взаимодействия его составляющих
Слайд 7 Исходные данные
Исходными данными для разработки программного продукта являются:
регистрация клиента в базе.
Выходные данные – это данные, которые
являются результатом работы программы. В данном случае выходными данными является
информация о клиенте.
Слайд 8 Главная страница
После открытия файла проекта открывается главная форма
программного модуля «Регистрация».
Данная форма предназначена для переключения на другие
формы: «Программа», «Задание», «Об проекте» и выхода из программы
Слайд 9 Страница «О проекте»
При переходе на вкладку «О проекте»
открывается основная информация о разработчике программы
Слайд 10 Способ обработки ошибок
В данной программе реализован следующий способ
обработки ошибок. Если не заполнено хотя бы одно поле,
то выводится сообщение об ошибке: «Какая-то ячейка не заполнена! Проверьте
Слайд 11 Страница «Программа»
— Это форма «Регистрация нового клиента» позволяющая
зарегистрировать нового клиента путем заполнения необходимых полей – это
и является непосредственно решением поставленной задачи
Слайд 12 Тестирование и откладка
Для тестирования программы зарегистрируем нового клиента
к уже имеющимся.
После того, как мы заполним все
поля в форме, необходимо нажать на кнопку «Сохранить данные о
клиенте».
После этого данные о новом клиенте, ФИО, марка автомобиля, количество дней, дата въезда, точное время въезда и стоимость стоянки заполнят таблицу Excel.
Слайд 13 Заключение
В результате курсового проектирования решены все поставленные задачи:
систематизированы, закреплены и углублены знания по прикладному программированию путем
использования их в курсовом проектировании; изучены стандарты, справочники, инструкции и
другая нормативно-техническая литература; развиты навыки грамотного изложения пояснительной записки, убедительного обоснования принятых решений; развито умение представлять и обоснованно защищать результаты своей работы.
Кроме того, выполнение курсового проекта позволило по-новому взглянуть на возможности системы Microsoft Office, использовать приобретённые навыки в дальнейшем курсовом и дипломном проектировании, выработать собственные подходы к решению не только учебных, но и профессиональных задач.
Источник: mypreza.com