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

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

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

• 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

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

61.1K

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

Верстка сайта – ремесло для посвященных

Есть в верстке сайта что-то таинственное. Но это до тех пор, пока не познакомишься с этим ремеслом поближе. Начинаем наше посвящение:

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

В процессе верстки кодом html происходит разбивка «скелета » сайта на части. А с помощью css (каскадных таблиц стилей ) задаются размеры его «костей », цвет и расположение.

Различают несколько видов верстки:

I. Табличная – ранее была основным способом верстки. В табличной верстке для задания структуры сайта используется тег

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

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

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

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

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

II. Блочная – в данный момент является основным способом верстки. В отличие от табличной блочная верстка обладает рядом преимуществ:

• Отделение стиля элементов от кода html ;
• Возможность наложения одного слоя на другой – такая возможность во многом облегчает позиционирование элементов.
• Лучшая индексация поисковиками;
• Высокая скорость загрузки страницы, состоящей от взаимно независимых элементов;
• Легкость создания визуальных эффектов (выпадающих меню, списков, всплывающих подсказок ).

Основным недостатком блочной верстки является некая «двусмысленность » понимания ее кода различными браузерами. Поэтому часто html страницы приходится «доводить » путем использования специальных хаков.

С появлением блочной верстки родилось такое понятие, как «кроссбраузерность». Из-за различия отображения одного и того же элемента в разных браузерах верстальщикам приходится вставлять в основной html целые куски кода (хаки).

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

Основным элементом, применяемым в блочной верстке, является тег

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

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

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

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

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