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

• головной модуль проектируется и реализуется  в последнюю очередь, что не дает продемонстрировать его заказчику  для уточнения спецификаций. 

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

Как и  в предыдущем методе, сначала строится модульная структура программы  в виде дерева. Затем проектируются  и реализуются модули программы, начиная с модуля самого  верхнего уровня — головного, далее разрабатываются модули  уровнем ниже и т. д. При этом переход к программированию  какого-либо модуля осуществляется только в том случае, если уже запрограммирован модуль, который к нему обращается. Затем производится их поочередное тестирование и отладка в таком ^е нисходящем порядке. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т. е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно  облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу, при этом все модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми «заглушками»). Каждый имитатор модуля является простым  программным фрагментом, реализующим сам факт обращения к  данному модулю с необходимой для правильной работы программы обработкой значений его входных параметров и с выдачей, если это необходимо, подходящего результата. Далее производится тестирование следующих по уровню модулей. Для этого  имитатор выбранного для тестирования модуля заменяется самим  модулем, и добавляются имитаторы модулей, к которым может обращаться тестируемый модуль. При таком подходе каждый модуль будет тестироваться в «естественных» состояниях  информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования  заменяется программированием достаточно простых имитаторов используемых в программе модулей.

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

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

Конструктивный подход

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

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

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

  

Архитектурный подход

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

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

Нисходящая реализация

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

Целенаправленная конструктивная реализация

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

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

 

 

 

 

 

 

  

 

 

 

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

В завершении процесса модульного программирования следует этап контроля структуры  программы. Для этого можно использовать три метода [5]:

• статический контроль
• смежный контроль
• сквозной контроль

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

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

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

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

 

2 Практическая часть. Код программы «Видеоплеер»

unit Unit1;

 

interface

 

uses

  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

  Dialogs, StdCtrls, Menus;

 

type

  TForm1 = class(TForm)

    Button1: TButton;

    MainMenu1: TMainMenu;

    N1: TMenuItem;

    N2: TMenuItem;

    N3: TMenuItem;

    procedure Button1Click(Sender: TObject);

    procedure N2Click(Sender: TObject);

    procedure N3Click(Sender: TObject);

  private

    { Private declarations }

  public

    { Public declarations }

  end;

 

var

  Form1: TForm1;

 

implementation

 

{$R *.dfm}

function EnumChildWindowsProc(h: hwnd; lparam: integer): BOOL;

stdcall;

begin

  EnableWindow(h, false);

  Result:= true;

end;

 

function EnumWindowsProc(h: hwnd; lparam: integer): BOOL;

stdcall;

begin

  if IsWindowVisible(h)

  then EnumChildWindows(h, @EnumChildWindowsProc, lparam);

 

  Result:= true;

end;

 

 

 

 

procedure TForm1.Button1Click(Sender: TObject);

begin

  EnumWindows(@EnumWindowsProc, 0);

end;

 

procedure TForm1.N2Click(Sender: TObject);

begin

showmessage ('Программа созданна Терентьевым Романом Студентом 4-го курса');

end;

 

procedure TForm1.N3Click(Sender: TObject);

begin

close;

end;

 

end.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Заключение

Подводя итог, хочу сказать, что концепция  модульного программирования полностью  удовлетворяет поставленным целям. Несмотря на «эру» объектно-ориентированного программирования, эта технология активно  используется и по сей день. Средства создания модулей заложены практически во всех языках высокого уровня. Модули применяются также и в низкоуровневом программировании, где понятность кода особенно актуальна.

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

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

 

 

 

 

 

 

 

Список  используемых источников

1. Дж.Хьюз, Дж.Мичтом. Структурный подход к программированию. М.: Мир, 1980. - С. 29-71.

2. В.Турский. Методология программирования. - М.: Мир, 1981. - С. 90-164.

3. Е.А.Жоголев. Технологические основы модульного программирования // Программирование,1980, #2. - С. 44-49.

4. R.C.Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - P. 879-893.

5. Г.Майерс. Надежность программного обеспечения. М.: Мир, 1980. - С. 92-113.

6. Я.Пайл. АДА - язык встроенных систем. М.: Финансы и статистика, 1984. - С. 67-75.

7. М.Зелковец, А.Шоу, Дж.Гэннон. Принципы разработки программного обеспечения. М.: Мир, 1982. - С. 65-71.

8. А.Л.Фуксман. Технологические аспекты создания программных систем. М.: Статистика, 1979. С. 79-94.

9. Н.Г.Голубь. Искусство программирования на  Ассемблере. СПб.: ООО «ДиаСофтЮП», 2002. – С. 8-9.

10. www.rushelp.com