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

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

Любое ПС имеет свою структуру, которая разрабатывается для удобства:

• 1. разработки
• 2. программирования
• 3. отладки
• 4. внесения изменений

Также структуризация ПС позволяет:

• 1. распределить работы по исполнителям, обеспечив их загрузку и требуемые сроки разработки
• 2. построить календарные графики проектных работ и осуществлять их координацию в процессе создания ПИ.
• 3. контролировать трудозатраты и стоимость проектных работ.

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

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

Типовая структура ПС:

носитель отладка программный модуль

Таблица. Типы модулей

Свойства модуля:

• 1. один вход и один выход - на входе программный модуль получает определенный набор исходных данных, выполняет обработку данных и возвращает результат
• 2. функциональная завершенность - модуль выполняет перечень операций для реализации каждой отдельной функции в полном составе.
• 3. логическая независимость - результат работы модуля зависит только от исходных данных, и не зависит от работы других модулей.
• 4. слабые информационные связи с другими программными модулями - обмен информации между модулями должен быть по возможности минимизирован.
• 5. обозримый по размеру и сложности.

Каждый модуль состоит из спецификации и тела модуля.

Спецификация - правила использования модуля.

Тело - способ реализации процесса обработки.

Принцип модульного программирования ПС:

• 1. Определение состава и подчиненность функций
• 2. определение набора программных модулей, реализующих эти функции

При составлении алгоритма необходимо учитывать:

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

Методы разработки структуры программы.

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

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

• 1. синтаксическую спецификацию его входов, позволяющую построить обращение к нему на используемом языке программирования
• 2. функциональную спецификацию модуля (описание всех функций, выполняемых этим модулем).

Существуют разные методы разработки структуры программы. Обычно используют 2 метода:

• 1. Метод восходящей разработки
• 2. метод нисходящей разработки

Метод восходящей разработки.

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

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

Метод нисходящей разработки.

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

Положительные стороны

• 1. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей.
• 2. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при "естественном" состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной, заменяются на их имитаторы. Имитатор модуля - простой программный фрагмент, сигнализирующий, о самом факте обращения к имитируемому модулю с необходимой для правильной работы программы обработкой значений его входных параметров и с выдачей, если это необходимо, заранее запасенного подходящего результата. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется на сам этот модуль и добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при "естественных" состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем "отладочного" программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для подыгрывания процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами.

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

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

Конструктивный подход (Модификация нисходящей разработки)

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

Рис. 7.1

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

Архитектурный подход (модификация восходящей разработки)

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

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

Рис. 7.2

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

Модульная структура программы

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

Усиление внутренних связей модулей;

Ослабление взаимосвязи между модулями.

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

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

Модульная структура библиотеки представлена в приложении Д на рисунке Д.1, визуализатора на рисунке Д.2.

Тестирование

Из всех этапов отладки программного обеспечения тестирование является самым трудоемким и дорогим. При создании типичного программного обеспечения на тестирование приходится около 40% общего времени и более 40% общей стоимости программного обеспечения.

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

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

Документирование

Техническое задание

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

6.1.1 Назначение разработки

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

6.1.2 Требования к программе или программному изделию

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

1) возможность введения входных данных, таких как минимальная и максимальная высота, размеры карты, крутизны гор;

2) генерация ландшафтов;

3) сохранение ландшафта для использования его в сторонних программах;

4) демонстрация получившегося результата, путем вывода картинки на экран.

6.1.3 Требования к надежности

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

6.1.4 Требования к составу и параметрам технических средств

Для минимального функционирования программы требуется: персональный компьютер, 2 ГБ оперативной памяти, 50 Мб свободного места на жестком диске; клавиатура, мышь.

Для оптимальной работы приложения необходимо оперативной памяти не менее 3ГБ оперативной памяти.

6.1.5 Требования к информационной и программной совместимости

Программа должна функционировать под управлением ОС семейства Windows 7 и выше; DirectX 11; Visual c++2015; .Net Framework 4.5 и выше.

6.1.6 Требования к программной документации

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

Руководство пользователя

Запуск программы производится запуском файла shell.exe, после запуска вы увидите окно, представленное на рисунке 6.1.

Вызвать меню «файл», можно с помощью кнопки «очистить» сбросить данные до стандартных значений. С помощью кнопки «Сохранить как bmp» сохранить карту высот в формате bmp. С помощью кнопки «Сохранить как obj» можно сохранить ландшафт в формате obj. Нажав на кнопку «Просмотр» запуститься визуализатор, в котором можно будет увидеть в трехмерном виде, представлен на рисунке 6.2.

Рисунок 6.1 - Окно программы

Рисунок 6.2 - Окно программы

Вызвать меню «настройки», можно с помощью кнопки «настройки программы» настроить программу для визуализации. С помощью кнопки «настройки визуализации» можно настроить визуализатор.

Движение в визуализаторе осуществляется кнопками на клавиатуре w, a, s, d, которые соответствуют направлениям вперед, влево, вправо, назад.

Управление камерой осуществляется мышкой.

Документация по работе с библиотекой

Для работой с библиотекой необходимо подключить файл LandscapeGenerator.dll к вашему проекту. В проекте необходимо объявить экземпляр класса LandscapeGenerator. Класс содержит следующие методы для изменения параметров ландшафта, такие как ширина, длина, минимальная и максимальная высота, гористость, генерации ландшафта, возврат ландшафта как bitmap, сохранение ландшафта в формате obj и bmp.

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

Отличия блочной вёрстки от табличной

Если табличная вёрстка подразумевает, что содержимое страницы находятся внутри тега

Единственный ощутимый минус блочной вёрстки - сделанные на ней сайты могут по-разному отображаться в обозревателях. Чтобы этого избежать, нужно делать вёрстку «кроссбраузерной», то есть одинаково отображаемой любым обозревателем.

Суть блочной вёрстки

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

Каждая часть страницы помещается в свой блок