Принципы модульного программирования программных продуктов во многом сходны с принципами нисходящего проектирования. Сначала определяются состав и подчиненность функций, а затем – набор программных модулей, реализующих эти функции.
Однотипные функции реализуются одними и теми же модулями. Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчиненные модули.
При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
каждый модуль вызывается на выполнение вышестоящим модулем и, закончив работу, возвращает управление вызвавшему его модулю;
принятие основных решений в алгоритме выносится на максимально » высокий» по иерархии уровень;
для использования одной и той же функции в разных местах алгоритма создается один модуль, который вызывается на выполнение по мере необходимости.
В результате дальнейшей детализации алгоритма создается функционально-модульная схема (ФМС) алгоритма приложения, которая является основой для программирования (рис. 18.3).
Что такое МОДУЛЬ шестерни? Ты ТОЧНО поймешь!
Рис. 18.3. Функционально-модульная структура приложения
Пример 18.5. Некоторые функции могут выполняться с помощью одного и того же программного модуля (например, функции Ф1 и Ф2).
Функция Ф3 реализуется в виде последовательности выполнения программных модулей.
Функция Фm реализуется с помощью иерархии связанных модулей.
Модуль n управляет выбором на выполнение подчиненных модулей.
Функция Фх реализуется одним программным модулем.
Состав и вид программных модулей, их назначение и характер использования в программе в значительной степени определяются инструментальными средствами. Например, применительно к средствам СУБД отдельными модулями могут быть:
экранные формы ввода и/или редактирования информации базы данных;
отчеты генератора отчетов;
стандартные процедуры обработки информации;
меню, обеспечивающее выбор функции обработки и др.
Алгоритмы большой сложности обычно представляются с помощью схем двух видов:
обобщенной схемы алгоритма – раскрывает общий принцип функционирования алгоритма и основные логические связи между отдельными модулями на уровне обработки информации (ввод и редактирование данных, вычисления, печать результатов и т.п.);
Наиболее часто детально проработанные алгоритмы изображаются в виде блок-схем согласно требованиям структурного программирования; при их разработке используются условные обозначения согласно ГОСТ 19.003-80 ЕСПД (Единая система программной документации). Обозначения условные графические, ГОСТ 19.002-80 ЕСПД. Схемы алгоритмов и программ. Правила обозначения.
СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ
Структурное программирование основано на модульной структуре программного продукта и типовых управляющих структурах алгоритмов обработки данных различных программных модулей (рис. 18.4).
Рис. 18.4. Блок-схема алгоритма поиска в базе данных
#Архитектура приложения и кода
В любой типовой структуре блок, кроме условного, имеет только один вход и выход, безусловный переход на блок с нарушением иерархии запрещен (оператор типа GoTo в структурном программировании не используется). Виды основных управляющих структур алгоритма приведены в табл. 18.1.
Пример 18.6. Алгоритм поиска в базе данных сведений о максимальном окладе сотрудников (рис. 18.4).
Таблица 18.1. Управляющие структуры алгоритмов
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ
Основные понятия объектно-ориентированного проектирования
Методика объектно-ориентированного проектирования
ОСНОВНЫЕ ПОНЯТИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ
Метод объектно-ориентированного проектирования основывается на:
модели построения системы как совокупности объектов абстрактного типа данных;
модульной структуре программ;
нисходящем проектировании, используемом при выделении объектов.
Объектно-ориентированный подход использует следующие базовые понятия:
Объект – совокупность свойств (параметров) определенных сущностей и методов их обработки (программных средств).
Объект содержит инструкции (программный код), определяющие действия, которые может выполнять объект, и обрабатываемые данные.
Свойство – характеристика объекта, его параметр. Все объекты наделены определенными свойствами, которые в совокупности выделяют объект из множества других объектов.
Объект обладает качественной определенностью, что позволяет выделить его из множества других объектов и обусловливает независимость создания и обработки от других объектов.
Например, объект можно представить перечислением присущих ему свойств:
ОБЪЕКТ_А (свойство-1, свойство-2. свойство-k).
Свойства объектов различных классов могут » пересекаться», т.е. возможны объекты, обладающие одинаковыми свойствами:
ОБЪЕКТ_В (. свойство-n, свойство-m. свойство-r. )
ОБЪЕКТ_С (. свойство-n. свойство-r. ).
Одним из свойств объекта являются метод его обработки.
Метод – программа действий над объектом или его свойствами.
Метод рассматривается как программный код, связанный с определенным объектом; осуществляет преобразование свойств, изменяет поведение объекта.
Объект может обладать набором заранее определенных встроенных методов обработки, либо созданных пользователем или заимствованных в стандартных библиотеках, которые выполняются при наступлении заранее определенных событий, например, однократное нажатие левой кнопки мыши, вход в поле ввода, выход из поля ввода, нажатие определенной клавиши и т.п.
По мере развития систем обработки данных создаются стандартные библиотеки методов, в состав которых включаются типизированные методы обработки объектов определенного класса (аналог – стандартные подпрограммы обработки данных при структурном подходе), которые можно заимствовать для различных объектов.
Событие – изменение состояния объекта.
Внешние события генерируются пользователем (например, клавиатурный ввод или нажатие кнопки мыши, выбор пункта меню, запуск макроса); внутренние события генерируются системой.
Объекты могут объединяться в классы ( группы или наборы – в различных программных системах возможна другая терминология).
Класс – совокупность объектов, характеризующихся общностью применяемых методов обработки или свойств.
Один объект может выступать объединением вложенных в него по иерархии других объектов.
Схематично связь основных понятий объектно-ориентированного программирования представим следующим образом (рис. 18.5).
Рис. 18.5. Соотношение основных понятий объектно-ориентированного подхода
В объектно-ориентированном программировании используется следующий формат записи работы с объектами:
Программный продукт, созданный с помощью инструментальных средств объектно-ориентированного программирования, содержит объекты с их характерными свойствами, для которых разработан графический интерфейс пользователя. Как правило, работа с программным продуктом осуществляется с помощью экранной формы, с объектами управления, которые содержат методы обработки, вызываемые при наступлении определённых событий. Экранные формы также используются для выполнения заданий и перехода от одного компонента программного продукта к другому. Каждый объект управления обладает определенными свойствами, значения которых могут изменяться. Для объектов управления уточняется перечень событий и создаются пользовательские методы обработки – программный код на языке программирования в виде событийных процедур.
Источник: lektsia.com
Модульная структура программных продуктов
Модульная структура программы представляет собой древовидную структуру, в узлах которой размещаются программные модули, а направленные дуги показывают статическую подчиненность модулей. Если в тексте модуля имеется ссылка на другой модуль, то их на структурной схеме соединяет дуга, которая исходит из первого и входит во второй модуль. Другими словами, каждый модуль может обращаться к подчиненным ему модулям. При этом модульная структура программной системы, кроме структурной схемы, должна включать в себя еще и совокупность спецификаций модулей, образующих эту систему [37].
Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчиненные модули.
При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
1) модуль вызывается на выполнение вышестоящим по иерархии модулем и, закончив работу, возвращает ему управление;
2) принятие основных решений в алгоритме выносится на максимально высокий по иерархии уровень;
3) если в разных местах алгоритма используется одна и та же функция, то она оформляется в отдельный модуль, который будет вызываться по мере необходимости.
Состав, назначение и характер использования программных модулей в значительной степени определяются инструментальными средствами.
Например, при разработке СУБД используются следующие программные модули:
1) экранные формы ввода и/или редактирования информации базы данных;
4) стандартные средства для обработки информации;
5) меню для выбора функции обработки и др.
Методы разработки при мольном программировании
Спецификация программного модуля состоит из функциональной спецификации модуля, описывающей семантику функций, выполняемых этим модулем по каждому из его входов, и синтаксической спецификации его входов, позволяющей построить на используемом языке программирования синтаксически правильное обращение к нему. Функциональная спецификация модуля определяется теми же принципами, что и функциональная спецификация программной системы.
Существуют разные методы разработки модульной структуры Программы, в зависимости от которых определяется порядок программирования и отладки модулей, указанных в этой структуре. Обычно в литературе обсуждаются два метода [42, 46]: метод восходящей разработки и метод нисходящей разработки.
Метод восходящей разработки
Сначала строится древовидная модульная структура программы. Затем поочередно проектируются и разрабатываются модули программы, начиная с модулей самого нижнего уровня, затем предыдущего уровня и т. д. То есть модули реализуются в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же восходящем порядке. Достоинство метода заключается в том, что каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Недостатки метода восходящей разработки заключаются в следующем:
• на нижних уровнях модульной структуры спецификации могут быть еще определены не полностью, что может привести к полной переработке этих модулей после уточнения спецификаций на верхнем уровне;
• для восходящего тестирования всех модулей, кроме головного, который является модулем самого верхнего уровня, приходится создавать вызывающие программы, что приводит к созданию большого количества отладочного материала, но не гарантирует, что результаты тестирования верны;
• головной модуль проектируется и реализуется в последнюю очередь, что не дает продемонстрировать его заказчику для уточнения спецификаций.
Метод нисходящей разработки
Как и в предыдущем методе, сначала строится модульная структура программы в виде дерева. Затем проектируются и реализуются модули программы, начиная с модуля самого верхнего уровня — головного, далее разрабатываются модули уровнем ниже и т. д. При этом переход к программированию какого-либо модуля осуществляется только в том случае, если уже запрограммирован модуль, который к нему обращается.
Затем производится их поочередное тестирование, и отладка в таком нисходящем порядке. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т. е. ликвидируется весьма неприятный источник просчетов при программировании модулей.
Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу, при этом все модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми «заглушками» [45]).
Каждый имитатор модуля является простым программным фрагментом, реализующим сам факт обращения к данному модулю с необходимой для правильной работы программы обработкой значений его входных параметров и с выдачей, если это необходимо, подходящего результата. Далее производится тестирование следующих по уровню модулей. Для этого имитатор выбранного для тестирования модуля заменяется самим модулем, и добавляются имитаторы модулей, к которым может обращаться тестируемый модуль. При таком подходе каждый модуль будет тестироваться в «естественных» состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей.
Недостатком нисходящего подхода к программированию является необходимость абстрагироваться от реальных возможностей выбранного языка программирования и придумывать абстрактные операции, которые позже будут реализованы с помощью модулей. Однако способность к таким абстракциям является необходимым условием разработки больших программных средств.
Рассмотренные выше методы (нисходящей и восходящей разработок), являющиеся классическими, требуют, чтобы модульная древовидная структура была готова до начала программирования модулей. Как правило, точно и содержательно разработать структуру программы до начала программирования невозможно. При конструктивном и архитектурном подходах к разработке модульная структура формируется в процессе реализации модулей.
Конструктивный подход
Конструктивный подход к разработке программы представляет собой модификацию нисходящей разработки, при которой модульная древовидная структура программы формируется в процессе программирования модуля. Сначала программируется головной модуль, исходя из спецификации программы в целом (спецификация программы является одновременно спецификацией головного модуля). В процессе программирования головного модуля в случае, если эта программа достаточно большая, выделяются подзадачи (некоторые функции) и для них создаются спецификации, реализующих эти подзадачи фрагментов программы. В дальнейшем каждый из этих фрагментов будет представлен поддеревом модулей (спецификация выделенной функции является одновременно спецификацией головного модуля этого поддерева).
Таким образом, на первом шаге разработки программы (при программировании ее головного модуля) формируется верхняя часть дерева, например, как на рис. 3.12
Спецификация программы
Рис. 3.12. Первый шаг формирования модульной структуры программы при конструктивном подходе
По тому же принципу производится программирование следующих по уровню специфицированных, но еще не запрограммированных модулей в соответствии со сформированным деревом. В результате к дереву добавляются очередные уровни, как показано на рис. 3.13.
Рис. 3.13. Второй шаг формирования модульной структуры программы при конструктивном подходе
Архитектурный подход
Архитектурный подход к разработке программы представляет собой модификацию восходящей разработки, при которой модульная структура программы формируется в процессе программирования модуля. Целью разработки в данном методе является повышение уровня языка программирования, а не разработка конкретной программы. Это означает, что для заданной предметной области выделяются типичные функции, специфицируются, а затем и программируются отдельные программные модули, выполняющие эти функции. Сначала в виде модулей реализуются более простые функции, а затем создаются модули, использующие уже имеющиеся функции, и т. д. Это позволяет существенно сократить трудозатраты на разработку конкретной программы путем подключения к ней уже имеющихся и проверенных на практике модульных структур нижнего уровня, что также позволяет бороться с дублированием в программировании. В связи с этим программные модули, создаваемые в рамках архитектурного подхода, обычно параметризуются для того, чтобы облегчить их применение настройкой параметров.
Нисходящая реализация
В классическом методе нисходящей разработки сначала все модули разрабатываемой программы программируются, а затем тестируются в нисходящем порядке. При этом тестирование и отладка модулей могут привести к изменению спецификации подчиненных модулей и даже к изменению самой модульной структуры программы. В результате может оказаться, что часть модулей вообще не нужна в данной структуре, а часть модулей придется переписывать. Более рационально каждый запрограммированный модуль тестировать сразу же до перехода к программированию другого модуля. Такой метод в литературе получил название метода нисходящей реализации.
Источник: infopedia.su
Тема 3.3.1 Модульная структура программного продукта
Модульное программирование – это логически взаимосвязанная совокупность функциональных элементов, оформленных в виде отдельных программных моду-лей.
— Один вход и один выход, на входе модуль получает набор исходных данных выполняет обработку и возвращает один набор результатных данных т.е. реализует стандартную функцию Input-Process-Output.
— Функциональная завершенность – модуль выполняет перечень операций для реализации каждой отдельной функции с полном составе.
— Логическая независимость – результат работы программного модуля зависит от исходных данных и не зависит от работы других модулей.
— Слабые информационные связи с другими программными модулями – обмен информацией между модулями должен быть минимальным.
— Обозримый по размеру сложности программный элемент.
Каждый модуль состоит из спецификации и тела. Спецификации определяют пра-вила использования модуля, а тело – способ реализации процесса обработки.
Принципы модульного программирования во многом схожи с нисходящим прое-ктированием, сначала определяется состав и подчиненность функции, а затем на-бор программных модулей реализующих эти функции. Функции верхнего уровня обеспечиваются главным модулем, он управляет выполнением нижестоящих фун-кций, которым соответствуют подчиненные модули. При определении набора модулей необходимо учитывать:
— каждый модуль вызывается на выполнение вышестоящим и закончив работу, возвращает управление вызвавшему его модулю;
— принятие основных решений в алгоритме выносится на максимально высокий уровень по иерархии уровней.
— для использования одной и той же функции в разных шестах создается один модуль, который вызывается на выполнение по мере необходимости.
В результате дальнейшей детализации алгоритма создается функциональная модульная схема (ФМС), которая является основой для программирования.
Рисунок 17 Функционально-модульная структура приложения
Некоторые фунции могут выполняться с помощью одного и того же программного модуля (например, функции Ф1 и Ф2).
* Функция Ф3 реализуется в виде последовательности выполнения программных модулей.
* Функция Фт реализуется с помощью иерархии связанных модулей.
* Модуль п управляет выбором на выполнение подчиненных модулей.
* Функция Фх реализуется одним программным модулем.
Ввод в действие
Структура программных продуктов
Графический интерфейс пользователя
Класс объектов
Источник: studopedia.su