Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Модульное программирование




СТРУКТУРНОЙ СХЕМЫ ПРОГРАММЫ

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

1) полнота выполнения специфицированных функций;

2)возможность быстрого и дешевого пополнения новыми, ра­нее не специфицированными функциями;

3)обозримость (понятность) для проектировщика составных частей программы;

4)максимальная независимость отдельных частей программы;

5) возможность связывания подпрограмм редактором связей;

6)достаточность оперативной памяти;

7) влияние топологии схемы иерархии на скорость выполнения программы при использовании динамической загрузки программы и механизма подкачки страниц;

8) отсутствие разных модулей со сходными функциями. Один и тот же модуль должен вызываться на разных уровнях схемы иерархии;

9)достижение такого графика работы коллектива программи­стов при реализации программы, который обеспечивает равномер­ную загрузку коллектива;

 

10)всемерное сокращение затрат на тестирование программы.
Хорошая схема иерархии в 2-5 раз сокращает затраты на тестиро­вание по сравнению с первоначальным вариантом;

11)использование в данном проекте как можно большего числа проработанных в предшествующих проектах модулей и библиотек при минимальном объеме изготавливаемых заново частей.

Генерация вариантов прекращается при невозможности даль­нейших улучшений. Рациональная структура программы обеспечи­вает сокращение общего объема текстов в 2-3 раза, что соответст­венно удешевляет создание программы и ее тестирование, на кото­рое обычно приходится не менее 60% от общих затрат. При этом облегчается и снижается стоимость сопровождения программы.

Реализация принципа структурного программирования осуществляется с использованием макрокоманд и механизмов вы­зова подпрограмм. Эти же механизмы подходят и для реализации модульного программирования, которое можно рассматривать как часть структурного подхода.

Необходимо различать использование слова модуль, когда име­ется в виду единица дробления большой программы на отдельные блоки (которые могут быть реализованы в виде процедур и функций) и когда имеется ввиду синтаксическая конструкция языков программирования (unit в Object Pascal).

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

Концепцию модульного программирования можно сформули­ровать в виде нескольких понятий и положений:

1) большие задачи разбиваются на ряд более мелких, функционально самостоятельных подзадач — модулей, которые связаны ме­жду собой только по входным и выходным данным;

2) модуль представляет собой «черный ящик» с одним входом и одним выходом. Это позволяет безболезненно производить мо­дернизацию программы в процессе ее эксплуатации, облегчает ее
сопровождение, а также позволяет разрабатывать части программодного проекта на разных языках программирования;

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

4) исходный текст модуля должен иметь заголовок и интер­фейсную часть, где отражаются назначение модуля и все его внеш­ние связи;

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

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

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

 

3.7. СТРУКТУРА МОДУЛЯ В OBJECT PASCAL

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

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

unit <идентификатор_модуля>;

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

{Интерфейсный раздел} interface

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

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

Связь модуля с другими модулями устанавливается специаль­ным предложением:

{Список импорта интерфейсного раздела} uses <список_модулей>

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

{Список экспорта интерфейсного раздела} const type var

procedure function

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

{Раздел реализации) implementation

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

{Список импорта раздела реализации) uses

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

{Подразделы внутренних для модуля описаний} label const type var

procedure function

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

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

{Раздел инициализации} initialization

В этом разделе между ключевыми словами initialization и finalization располагаются операторы начальных установок, необходимых для запуска корректной работы модуля. Эти опера­торы исполняются до передачи управления основной программе и обычно используются для подготовки ее работы. Операторы раз­делов инициализации модулей, используемых в программе, выпол­няются при начальном запуске программы в том же порядке, в ка­ком идентификаторы модулей описаны в предложениях uses фай­ла проекта. Если операторы инициализации не требуются, то зарезервированное слово initialization может быть опущено.

{Раздел завершения) finalization

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

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

 




Поделиться с друзьями:


Дата добавления: 2014-12-16; Просмотров: 768; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.018 сек.