Глава 4. АРХИТЕКТУРА ПРОГРАММНЫХ СИСТЕМ

 

4.1.  ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ

 

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

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

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

            Примеры систем: ОС, СУБД, система продажи авиабилетов и др. Примеры программ: редактор текстов, компилятор, программы посылки запросов от кассира и др.

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

 

4.2.  СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ

 

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

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

            Уже в конце 70-х годов этим способом можно было быстро реализовать весьма удобный ввод данных в программу. Применительно к более поздней операционной системе MS DOS достаточно было написать текстовый файл maket.txt с текстами пояснений сути данных и символом «?» обозначить поля вводимых данных. Далее готовился командный файл с последовательностью команд:

            1) — удаление файла work.txt с диска;

            2) — копирование файла maket.txt  в файл work.txt;

            3) — запуск готовой программы текстового редактора с параметром work.txt;

            4) — запуск программы пользователя обработки данных (входная информация программы — файл result.txt. выходная информация программы — файл result.txt);

            5) — запуск готовой программы просмотра текстовых файлов с параметром result.txt.

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

            Если надо реализовать меню выбора отдельных программ, то невозможно обойтись последовательным вызовом команд командного файла. Для этого случая можно написать программу, которая визуализирует меню на экране и возвращает номер выбранного пользователем меню операционной системе. Возвратить номер выбранной темы меню можно вызовом подпрограммы Halt(номер_мен) модуля DOS Turbo Pascal, где номер мен — значение выбранного номера темы меню.

           Далее, используя команды DOS, организуйте вызов нужных программ командным файлом:

            IF ERRORLEVEL 2 GOTO ITEM2

            IF ERRORLEVEL 1 СОТО ITEM1

             . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

            :ITEM1

             . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

            :ITEM2

 

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

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

            Хотя проектирование систем из отдельных программ выполняется, по крайней мере, последние 30 лет, но не выработано никакой методики, кроме не особенно полезного совета: изобразите функциональную схему процесса, а затем разбейте процесс на программы.

 

            

 

              4.3.  СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ

 

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

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

 

4.3.  СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ

 

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

 

4.4.  ПОДХОД К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ СИСТЕМЫ НА ОСНОВЕ АБСТРАКТНЫХ МАШИН ДЕЙКСТРЫ

 

            Самый нижний уровень абстракции — это уровень аппаратуры. Каждый уровень реализует абстрактную машину с все большими возможностями.

            Принцип 1. На каждом уровне абсолютно ничего не известно о свойствах более высоких уровней. Этим достигается сокращение связей между уровнями. 

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

            Принцип 3. Каждый уровень представляет собой отдельно откомпилированные программы.             Некоторые из этих модулей являются внутренними для уровня, т. е. недоступными другим уровням. Имена остальных модулей известны на более высоком уровне и представляют собой сопряжения с этим уровнем.

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

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

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

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

            Принцип 8. Всякая функция, выполняемая уровнем абстракции, должна быть представима единственным входом. Аргументы, пересылаемые между уровнями, должны быть отдельными элементами данных, а не сложными структурами.

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

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

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

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

            После установки операционной системы MS Windows 3.1 (при установке операционной системы MS Windows 95 одновременно устанавливается и MS DOS) появляются новые команды управления окнами для работы специалистов «со столами, заваленными бумагами». Появляется возможность одновременного запуска разных программ в разных окнах с возможностью междуоконного обмена информацией.

            После установки программного комплекса Microsoft Office появляются среды и команды работы над документами, расчетными таблицами и т.д.

 

4.5.  СОМ — ТЕХНОЛОГИЯ РАЗРАБОТКИ РАЗВИВАЮЩИХСЯ И РАССРЕДОТОЧЕННЫХ КОМПЛЕКСОВ ПРОГРАММ

 

            СОМ — Component Object Model (модель компонентных объектов) — это спецификация метода создания компонент и построения из них программ.

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

            Традиционно программа проектировалась из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое.

            Компоненты СОМ представляют собой исполняемый код, обычно распространяемый в виде динамически компонуемых библиотек (DLL). Компоненты СОМ подключаются друг к другу динамически.

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

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

            СОМ — это технология разработки развивающихся и рассредоточенных (многомашинных) комплексов программ, основанная на модели компонентных объектов.

            Главное в СОМ — следование стандартным спецификациям интерфейса компонент. Однажды принятый стандарт спецификаций интерфейса никогда не изменяется. Однако после разработки нового стандарта новые компоненты сами будут опознавать старый и новый стандарты. После достаточной замены числа компонент программа вдруг заработает по-новому!

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

            Пользователи часто хотят адаптировать программы к своим нуждам. Конечные пользователи предпочитают, чтобы программа работала так, как они привыкли. Программистам в крупных организациях нужны адаптируемые приложения, чтобы создавать специализированные решения на основе готовых продуктов. Компонентные архитектуры хорошо приспособлены для адаптации, так как любую компоненту можно заменить другой, более соответствующей потребностям пользователя. Предположим, что у нас есть компоненты на основе редакторов vi и Emacs рис. 4.1. Пользователь 1 может настроить программы на использование vi, тогда как пользователь 2 предпочтет Emacs. Программы можно легко настраивать, добавляя новые компоненты или заменяя имеющиеся.

 

 

            Один из самых многообещающих аспектов внедрения компонентной архитектуры — быстрая разработка программ. Вы сможете выбирать компоненты из библиотеки и составлять из них, как из деталей конструктора, цельные приложения методом морфологического синтеза! Практически все продаваемые сегодня приложения Microsoft используют СОМ. Технология ActiveX этой фирмы построена на основе компонент СОМ. Программисты на Visual Basic, С++, Delphi и Java могут воспользоваться управляющими элементами ActiveX для ускорения разработки своих приложений и страниц Web. Конечно, каждому приложению по-прежнему будут нужны и некоторые специализированные компоненты, но для построения простых приложений можно обойтись стандартными.

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

            Преимущества использования компонент непосредственно вытекают из способности последних подключаться к приложению и отключаться от него. Для этого компоненты должны удовлетворять двум требованиям. Во-первых, они должны компоноваться динамически. Во-вторых, должны скрывать (или инкапсулировать) детали своей реализации. Чтобы понять, как это связано с инкапсуляцией, необходимо определить некоторые термины. Программа или компонента, использующая другую компоненту, называется клиентом (client). Клиент подсоединяется к компоненте через интерфейс (interface). Если компонента изменяется без изменения интерфейса, то изменений в клиенте не потребуется. Аналогично если клиент изменяется без изменения интерфейса то нет необходимости изменять компоненту. Однако если изменение либо клиента, либо компоненты вызывает изменение интерфейса, то и другую сторону интерфейса также необходимо изменить.

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

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

            Ограничение 1. Компонента должен скрывать используемый язык программирования.   Компоненты могут быть разработаны с помощью практически любого процедурного языка, включая Ada, С, Java, Modula-З, Oberon и Pascal. Любой язык, в том числе Smalltalk и Visual Basic, можно приспособить к использованию компонент СОМ. Любой клиент должен иметь возможность использовать компоненту независимо от языков программирования, на которых написаны тот и другой.

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

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

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

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

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

 

 

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

 

            ВЫВОДЫ

 

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

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

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

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

 

Глава 5. ТЕХНОЛОГИЯ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ

 

            5.1. ПОНЯТИЕ СТРУКТУРЫ ПРОГРАММЫ

 

            Структура программы — искусственно выделенные программистом взаимодействующие части программы. Использование рациональной структуры устраняет проблему сложности разработки; делает программу понятной людям; повышает надежность работы программы при сокращении срока ее тестирования и сроков разработки вообще.

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

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

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

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

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

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

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

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

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

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

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

 

            5.2. МОДУЛЬ И ОСНОВНЫЕ ПРИНЦИПЫ СТРУКТУРНОГО ПОДХОДА

 

            5.2.1. Понятие модуля

 

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

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

            Модуль — фундаментальное понятие и функциональный элемент технологии структурного программирования.

            Модуль — это подпрограмма, но оформленная в соответствии с особыми правилами.

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

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

            Правило 3. Модуль может вызывать другие модули по их именам.

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

            Правило 5. Модуль кодируется только стандартными структурами и тщательно комментируется.

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

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

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

 

 

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

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

            Расчленение должно обеспечивать удобный порядок ввода частей в эксплуатацию.

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

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

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

            Структурный подход рекомендует соблюдать следующие принципы при создании программного изделия:

            — модульность программ;

            — структурное кодирование модулей программ;

            — нисходящее проектирование рациональной иерархии модулей программ;

            — нисходящая реализация программы с использованием заглушек;

            — осуществление планирования на всех стадиях проекта;

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

            Модульность программ характеризуется тем, что вся программа состоит из модулей. Некоторые смысловые группы модулей сосредоточиваются в отдельных файлах. Например, в отдельных файлах (Unit) могут быть сосредоточены модули текстового редактора и модули иерархического меню.

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

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

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

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

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

 

 

            5.2.2. Понятие заглушки модуля

 

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

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

            Написание заглушек — «лишняя» работа, но требуется искусство проектировщика, чтобы максимальное количество заглушек были простыми, а тестирование уже собранной части программы было бы полным.

 

 

 

            5.2.3. Средства изменения топологии иерархии программы

 

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

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

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

 

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

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

 

            5.2.4. Критерии оценки качества схемы иерархии

 

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

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

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

            Фонд критериев оптимальности схем иерархии является необходимым подспорьем при оптимизации схем иерархии и состоит из 13 критериев.

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

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

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

            Пятый — возможность связывания программы с обширной многоуровневой схемой иерархии конкретным редактором связей (линковщиком). Если начинаете работать над новой программой, то очень полезно выполнить на ЭВМ ее модель в виде пустых заглушек модулей, которые не содержат никаких действий.

            Шестой — достаточность оперативной памяти. Здесь рассматриваются варианты с описанием особенно структурированных статических и динамических переменных на разных уровнях схемы иерархии. Проверка удовлетворения данного критерия осуществляется расчетами с некоторыми машинными экспериментами.

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

            Восьмой — отсутствие разных модулей, выполняющих похожие действия. В идеале — один и тот же модуль вызывается на разных уровнях схемы иерархии.

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

            Десятый — всемерное сокращение затрат на тестирование уже собранного ядра программы по ключевым датам сетевого графика реализации. Характеризуется простотой используемых заглушек и качеством тестирования по всем вычислительным маршрутам модулей. Достигается первичной реализацией сверху вниз модулей ввода и вывода программы с отсрочкой реализации остальных ветвей схемы иерархии. Обычно затраты на тестирование как по срокам, так и деньгам составляют около 60% стоимости всего проекта. Хорошая схема иерархии сокращает затраты на тестирование по сравнению с первоначальным вариантом в 2 — 5 раз и более.

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

            Двенадцатый — удачное распределение модулей по компилируемым файлам программы и библиотекам.

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

            Итак, хорошая структура программы обеспечивает сокращение общего объема текстов в 2 или 3 раза, что соответственно удешевляет проект; на несколько порядков удешевляет тестирование (на тестирование обычно приходится не менее 60% от общих затрат проекта), а также облегчает и удешевляет сопровождение программы.

 

            5.2.5. Рекомендации по организации процесса разработки схемы иерархии

 

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

            Отдельные варианты структуры программы разрабатываются до достижения возможности их сравнения. При этом используются следующие документы:

            • описание алгоритма (функционирования) программы или методов решения задачи вместе с описанием данных;

            • схема иерархии модулей программы с расшифровкой обозначений и функций модулей;

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

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

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

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

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

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

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

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

            Существует очень много автоматизированных систем по формированию декомпозиции схем иерархии, например HIPO, SADT, R-TRAN.

 

            5.3. РЕТРОСПЕКТИВНОЕ ПРОЕКТИРОВАНИЕ  ДЕМОНСТРАЦИОННОЙ ПРОГРАММЫ MCALC  ФИРМЫ «BORLAND INC».

 

            Согласно ретроспективно проведенного системного анализа (см. гл. 2), фирма «Borland Inc.» приняла решение о реализации демонстрационного примера программы электронной таблицы. Вполне возможно сгенерировать множество вариантов реализации электронной таблицы, начиная от варианта со всеми клетками в одном окне и кончая, например, вариантом Excel. Однако фирма «Borland Inc.» избрала вариант с прокруткой информации клеток в окне, изменением адресов клеток при вставках строк и столбцов, а также при их удалении. В проект введены требования разработки некоммерческого изделия. Размер таблицы ограничен 100 ·100 клетками. В программе отсутствует функция копирования клеток. Избранная сложность реализуемого варианта соответствует много файловому проекту. Программа имеет функции поддержки вывода на дисплей, ввода с клавиатуры; в ней реализован интерпретатор формул с математическими функциями; для сохранения информации таблицы используется файл сложной организации. Все это позволяет продемонстрировать возможности компилятора.

            Программа Mcalc 1985 — 1988 гг. (Turbo Pascal 5.0) состоит из следующих файлов:

            → mcalc.pas — файл основной программы;

            → mcvars.pas — файл глобальных описаний;

            → mcdisply.pas — файл подпрограмм работы с дисплеем;

            → mcmvsmem.asm — ассемблерный файл подпрограмм запоминания в оперативной памяти информации экрана, а также восстановления ранее сохраненной информации экрана;

            → mcinput.pas — файл подпрограмм ввода данных с клавиатуры;

            → mcommand.pas — файл подпрограмм, обслуживающих систему меню и действий, выбранных посредством меню;

            → mcutil.pas — файл вспомогательных подпрограмм;

            → mcparser.pas — файл интерпретатора арифметических выражений формул клеток.

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

            Хотя фирма «Borland Inc.» занимается разработкой компиляторов, файл mcparser.pas также является заимствованным из UNIX YACC utility и лишь частично модифицированным. Остальные файлы являются оригинальными.

            Ассемблерный файл mcmvsmem.asm является искусственно добавленным. Цель его добавления — демонстрация возможности использования ассемблерных вставок.   Содержащиеся в нем алгоритмы вполне можно было бы реализовать на языке Pascal. Более того, можно было бы вообще обойтись без реализованных в нем подпрограмм, правда, при этом были бы видны некоторые задержки вывода информации на экран.

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

            Рассмотрим организацию файла mcvars.pas, содержащего в основном описание структуры внутренних данных программы. Файл содержит описания в секции interface. Секция implementation пустая.

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

 

 

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

            — блок парных строк текстов меню и «горячих» клавиш выбора тем меню;

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

 

 

            — блок описания цветов всех полей экрана, модификация констант которого позволяет оперативно изменять цвета;

            — основные константы, мнемоника имен которых облегчает восприятие текстов программы

 

 

            — коды управляющих клавиш клавиатуры.

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

            Далее следуют описания типа информации содержимого табличной клетки и типа указателя на клетку:

 

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

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

 

 

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

            Следует отметить, что выделение отдельного массива форматов информации клеток не оправдано было бы. Практичнее ввести байт информации формата клетки в тип CellRec.

            Для составления оставшейся проектной документации выполним трассировку программы. После двойного нажатия клавиши, <F7> начинает исполняться настроечный код, содержащийся в файлах *.TPU, и далее начинают выполняться операторы основной программы program Mcalc, находящейся в файле mcalc.pas.

            В результате исследований была выявлена схема иерархии модулей программы, изображенная на рис. 5.3 — 5.5.

 

 

 

 

 

 

 

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

 

            HeapError := @HeapFunc;

 

            В файле mcdisplay.pas последовательно выполняются подпрограммы: InitDisplay, GetSetCursor, Window, EGAInsalled.

            Процедура InitDisplay инициализирует видеокарту на работу в режиме 80 25 при помощи вызова прерывания 10h и вызовом процедуры InitColorTable инициализирует массив пересчета цветов для монохромного монитора. Последний массив используется при вызовах процедуры SetColor.

                Процедура GetSetCursor при помощи процедуры GetCursor считывает толщину курсора в переменную OldCursor и при помощи процедуры SetCursor устанавливает новую толщину курсора (NOCURSOR).

            Процедура Window определяет окно на экране дисплея для размещения информации всей таблицы. Далее начинает выполняться код главной программы Mcalc.

            Присваиванием CheckBreak:= False запрещается использование клавиши <Ctrl+Break> немедленного завершения программы.

            Вывод начальной заставки осуществляется следующими вызовами подпрограмм.   Процедурами SetColor и ClrScr производится очистка окна программы. Двойным вызовом процедур SetColor и WriteXY выводятся две строки начальной заставки. Несмотря на отсутствие курсора, отрабатывается рудиментарный вызов «сокрытия» курсора GotoXY(80,25). При помощи функции GetKey осуществляется ожидание нажатия пользователем любой клавиши.

            Процедурами SetColor и ClrScr производится очистка окна программы.

            Вызовом процедуры InitVars инициализируются значения основных переменных программы. Массивы инициализируются значениями по умолчанию вызова процедуры FillChar.

            Присваиванием Changed:= False указывается факт неизменности информации клеток таблицы после момента инициализации переменных для запрещения срабатывания авто сохранения.

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

            Если значение ParamCount = 1, то в командной строке MS DOS вызова программы было указано имя файла таблицы. В этом случае выполняется процедура LoadSheet, которая загружает информацию таблицы из файла с именем файла, полученном при помощи вызова функции ParamStr.

            Наконец, отрабатывает «лишний» вызов Clearinput, который дублируется в начале последующей процедуры Run, содержащей главный цикл программы.

            При завершении выполнения программы последовательно производится установка цвета экрана, вызовом TextMode переводится экран в текстовый режим, запомненный в переменной OldMode, и, наконец, вызовом SetCursor восстанавливается толщина курсора, запомненная в переменной OldCursor.

            Работа процедуры RedrawScreen заключается в последовательном выводе на экран информации:

            → процедурой SetRightCol выводится на экран строка с наименованиями столбцов таблицы;

            → процедурой SetBottomRow выводится на экран колонка с номерами строк таблицы;

            → процедурами GotoXY и Write выводятся надписи в верхней строке экрана, хотя имеется более удобная процедура WriteXY;

            → выводится число остатка байт памяти;

            → процедурой DisplayScreen отображается на экране внутренняя информация таблицы.

            Внешний вид программы Mcalc приведен на рис. 5.6.

            Работа процедуры Run начинается с установления переменной главного цикла Stop:= False и выполнения процедуры ClearInput. Главный цикл программы выполняется до изменения значения переменной Stop на True. Такое изменение возможно лишь при выборе пользователем темы меню Quit             — завершение работы с программой.

Внутри главного цикла последовательно выполняются следующие действия:

            — при помощи процедуры DisplayCell выводится на экран подсвеченная клеточным курсором текущая клетка (клетка Al на рис. 5.6);

            — при помощи процедуры ShowCellType выводится в нижнем левом углу экрана надпись типа текущей клетки таблицы (см. рис. 5.6);

            — оператором Input:= GetKey в переменную Input вводится код символа клавиши, нажатой пользователем;

            — выполняются действия отработки клавиши, нажатой пользователем. Действия отработки клавиши, нажатой пользователем, представляют собой цепочку альтернативных действий, реализованную структурой ВЫБОР. Сначала отрабатываются действия «горячих»

 

 

клавиш. В секции default (если клавиша не была «горячей») вызовом процедуры GetInput начинается занесение информации в текущую клетку таблицы. Процедура GetInput, занеся символ Input в редактируемую строку, первоначально вызывает EditString — редактор текстовой строки информации клетки и затем вызывает процедуру Act, которая обрабатывает информацию введенной строки, занося ее в клетку.

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

            С целью повышения понятности программы были приняты новые проектные решения, отраженные схемой иерархии (рис. 5.7).

            Выполнение основной программы Mcalc начинается с запуска нового модуля Starting подготовительных действий программы. Модуль Starting является монитором последовательного исполнения модулей InitDisplay, Greeter, InitVars.

            Новый модуль InitDisplay теперь является монитором последовательного исполнения модулей GetSetMode, GetCursor, SetCursor, EgaInstalled, Window, InitColorTable.

            У нового модуля GetSetMode явно в качестве входного параметра указывается новый устанавливаемый видеорежим, а на выходе — старый видеорежим. Такая организация предпочтительнее прямого вызова Intr, поскольку по списку формальных параметров ясно видно назначение модуля. Реализация двух функций по выявлению и установке видеорежимов в одном модуле здесь вполне оправдана, поскольку все они реализуются вызовом одного прерывания.

            Не является оправданным использование модуля с двумя функциями GetSetCursor, который являлся монитором последовательного исполнения модулей GetCursor, SetCursor. Этот модуль исключен из проекта. Все функции вывода начальной заставки переданы новому модулю Greeter.

            Из модуля RedrawScreen исключен вызов модуля DisplayScreen. Это позволило избежать повторного вызова модуля DisplayScreen в модуле LoadSheet. Также исправлена ошибка использования операторов Write для вывода информации на экран путем использования вызовов процедуры WriteXY.

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

                If (not (HotKey (Input)) and (ConditionalKey (Input)))

                then

                GetInput(Input).

            Новая функция HotKey в случае нажатия пользователем горячей клавиши возвращает значение TRUE, в противном случае функция возвращает значение FALSE.

 

 

 

            Новая функция ConditionalKey в случае нажатия пользователем клавиши с кондиционным для занесения в таблицу кодом возвращает значение TRUE, в противном случае функция возвращает значение FALSE.

            Новая процедура WriteXY теперь не использует вызов медленной процедуры GotoXY и медленно выполняемый оператор Write и использует прямой доступ к видеопамяти. Это позволило значительно ускорить вывод информации на дисплей. Более того, в процедуру добавлен новый параметр атрибута цвета выводимой строки, что позволило избежать цепочек первоначального вызова SetColor, а затем WriteXY.

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

 

            ВЫВОДЫ

 

            • Структура программы — искусственно выделенные программистом взаимодействующие части программы. Использование рациональной структуры устраняет проблему сложности разработки; делает программу понятной людям; повышает надежность работы программы при сокращении срока ее тестирования и сроков разработки вообще.

            • Модуль — функциональный элемент технологии структурного программирования. Это подпрограмма, но оформленная в соответствии с особыми правилами.

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

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

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

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

 

         Глава 6. ТЕХНОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

 

            6.1.ИСТОРИЯ СОЗДАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

 

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

            Были разработаны три основополагающих принципа того, что потом стало называться объектно-ориентированным программированием (ООПр): наследование; инкапсуляция; полиморфизм.

            Результатом их первого применения стал язык Симула-1 (Simula-1), в котором был введен новый тип — объект. В описании этого типа одновременно указывались данные (поля) и процедуры, их обрабатывающие — методы. Родственные объекты объединялись в классы, описания которых оформлялись в виде блоков программы. При этом класс можно использовать в качестве префикса к другим классам, которые становятся в этом случае подклассами первого. Впоследствии Симула-1 был обобщен, и появился первый универсальный О ОП — ориентированный язык программирования — Симула-67 (67 — по году создания).

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

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

 

 

            6.2. ВВЕДЕНИЕ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММ

 

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

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

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

            Объектно-ориентированное мышление адекватно способу естественного человеческого мышления, ибо человек мыслит «образами» и «абстракциями». Чтобы проиллюстрировать некоторые из принципов объектно-ориентированного мышления, обратимся к следующему примеру, основанному на аналогии мира объектов реальному миру.

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

            Таким образом, для решения своей проблемы вы нашли объект «кассир железнодорожной кассы» и передали ему сообщение, содержащее запрос. Обязанностью объекта «кассир железнодорожной кассы» является удовлетворение запроса.

            У кассира имеется некоторый определенный метод или эвроритм, или последовательность операций (процедура), которые используют работники кассы для выполнения вашего запроса. Имеются у кассира и другие методы, например по сдаче денег, — инкассации.

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

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

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

            Помимо методов, кассир для успешной работы должен располагать наборами чистых бланков билетов, купюрами и монетами наличных денег (хотя бы для сдачи покупателю). Такие наборы хранятся в особых отсеках кассы, особых коробках. Места хранения этих наборов называют полями объектов. В программах полям объектов соответствуют переменные, которые могут хранить какие-то значения.

            Покупатель билета не может положить деньги непосредственно в отсек кассового аппарата или сейф кассира, а также самостоятельно отсчитать себе сдачу. Таким образом, кассир как бы заключен в оболочку или капсулу, которая отделяет его и покупателя от лишних взаимодействий. Помещение кассы (капсула) имеет особое устройство, исключающее доступ покупателей билетов к деньгам. Это и есть инкапсуляция объектов, позволяющая использовать только допустимый интерфейс — обмен информацией и предметами только посредством допустимых сообщений, а может быть, еще и подаваемых в нужной последовательности. Именно только через вызов сообщениями особых методов осуществляется обмен данных, отделяя покупателей от полей. Благодаря инкапсуляции покупатель может лишь отдавать в качестве оплаты деньги за билет в форме сообщения с аргументом «сумма». Аналогично, но в обратном направлении кассир возвращает сдачу.

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

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

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

            Фундаментальной концепцией в объектно-ориентированном программировании является понятие классов. Все объекты являются представителями, или экземплярами, классов. Например: у вас наверняка есть примерное представление о реакции кассира на запрос о заказе билетов, поскольку вы имеете общую информацию о людях данной профессии (например, кассире кинотеатра) и ожидаете, что он, будучи представителем данной категории, в общих чертах будет соответствовать шаблону. То же самое можно сказать и о представителях других профессий, что позволяет разделить человеческое общество на определенные категории по профессиональному признаку (на классы).         Каждая категория в свою очередь делится на представителей этой категории. Таким образом, человеческое общество представляется в виде иерархической структуры с наследованием свойств классов объектов всех категорий. В корне такой классификации может находиться класс «HomoSapience» или даже класс «млекопитающие» (рис. 6.1).

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

            Классы могут быть организованы в иерархическую структуру с наследованием свойств. Класс-потомок наследует атрибуты родительского класса, расположенного ниже в иерархическом дереве (если дерево иерархии наследования растет вверх). Абстрактный родительский класс — это класс, не имеющий экземпляров объектов. Он используется только для порождения потомков. Класс «HomoSapience», скорее всего, будет абстрактным, поскольку для практического применения, например работодателю, экземпляры его объектов не интересны.

            Итак, пусть абстрактным родительским классом у работодателя будет класс «трудоспособный человек», который включает методы

 

доступа к внутренним данным, а также поля самих внутренних данных: фамилия; имя; отчество; дата рождения; домашний адрес; домашний телефон; сведения об образовании; сведения о трудовом стаже и т. д. От данного класса могут быть унаследованы классы: «кассир», «водитель автомобиля», «музыкант». Класс «кассир» располагает методами работы: общение с клиентом по правилам, получение денег, выдача денег, общение с инкассатором и т. д. От класса «кассир» могут быть унаследованы классы: «кассир, выдающий зарплату», «кассир железнодорожной кассы». Кассир железнодорожной кассы отличается от кассира, выдающего зарплату, дополнительными знаниями и навыками работы. От класса «кассир железнодорожной кассы» могут быть получены экземпляры объектов: «кассир кассы № 1», «кассир кассы № 2», «кассир кассы № 3» и т.д.

            В помещении большого вокзала можно обнаружить множество одинаково оборудованных объектов — касс. Однако среди касс можно выделить различающиеся кассы: суточные, предварительные, воинские, работающие по бронированию билетов и т. д. Для того чтобы начальнику вокзала поменять один вид кассы на другой, нет необходимости перестраивать помещение кассы и менять оборудование. Ему достаточно заменить в кассе кассира с одними навыками на кассира с другими навыками. Кассир вставляет табличку с новой надписью вида кассы — и все. Заметим, что смена функции касс произошла без остановки работы вокзала. Такая замена становится простой именно потому, что все помещения касс имеют одинаковый интерфейс с кассирами и клиентами.        Теперь разные объекты, поддерживающие одинаковые интерфейсы, могут выполнять в ответ на запросы разные операции.

            Ассоциация запроса с объектом и одной из его операций во время выполнения называется динамическим связыванием. Динамическое связывание позволяет во время выполнения подставить вместо одного объекта другой, если он имеет точно такой же интерфейс. Такая взаимозаменяемость называется полиморфизмом и является еще одной фундаментальной особенностью объектно-ориентированных систем (рис. 6.2).

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

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

            Композиция объектов — это реализация составного объекта, состоящего из нескольких совместно работающих объектов и образующих единое целое с новой, более сложной функциональностью.

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

 

данного класса быть ладьей, слоном, ферзей, пешкой и т. д. По второму способу после получения классов «ладья» и «слон» их можно объединить композицией в класс «ферзь». Теперь объект класса «ферзь» можно использовать как объект «ферзь» или даже как объект «слон», для чего объекту «ферзь» делегируется выполнение полномочий слона. Более того, можно делегировать объекту «ферзь» полномочия стать объектами «король» или даже «пешка»! Для композиции требуется, чтобы объединяемые объекты имели четко определенные интерфейсы. И у наследования, и у композиции есть достоинства и недостатки.

            Наследование класса определяется статически на этапе компиляции; его проще использовать, поскольку оно напрямую поддержано языком программирования.

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

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

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

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

            Это подводит еще к одному правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса.  

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

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

            С помощью делегирования композицию можно сделать столь же мощным инструментом повторного использования, сколь и наследование. При делегировании в процесс обработки запроса вовлечено два объекта: получатель поручает выполнение операций другому объекту — уполномоченному. Примерно так же подкласс делегирует ответственность своему родительскому классу. Но унаследованная операция всегда может обратиться к объекту-получателю через переменную-член (в С++) или переменную self (в Smalltalk). Чтобы достичь того же эффекта для делегирования, получатель передает указатель на самого себя соответствующему объекту, чтобы при выполнении делегированной операции последний мог обратиться к непосредственному адресату запроса.

            Например, вместо того чтобы делать класс Window (окно) подклассом класса Rectangle (прямоугольник) — ведь окно является прямоугольником, — мы можем воспользоваться внутри Window поведением класса Rectangle, поместив в класс Window переменную экземпляра типа Rectangle и делегируя ей операции, специфичные для прямоугольников. Другими словами, окно не является прямоугольником, а содержит его. Теперь класс Window может явно пере направлять запросы своему члену Rectangle, а не наследовать его операции.

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

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

            Таким образом, можно выделить следующие фундаментальные характеристики объектно-ориентированного мышления:

            Характеристика 1. Любой предмет или явление могут расы сматриваться как объект.

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

            Характеристика 3. Объекты могут иметь открытые по интерфейсу методы обработки сообщений. Сами сообщения вызовов методов посылаются другими объектами, но для осуществления разумного интерфейса между объектами некоторые методы могут быть скрыты.

            Характеристика 4. Вычисления осуществляются путем взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие (метод). Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия. Объект — получатель сообщения — обрабатывает сообщения своими внутренними методами.

            Характеристика 5. Каждый объект является представителем класса, который выражает общие свойства объектов данного класса в виде одинаковых списков набора данных (полей) в своей памяти и внутренних методов, обрабатывающих сообщения. В классе методы задают поведение объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.

            Характеристика 6. Классы организованы в единую квазидревовидную структуру с общим корнем, которая называется иерархией наследования. Обычно корень иерархии направлен вверх. При множественном наследований ветви могут срастаться, образуя сеть наследования. Память и поведение, связанные с экземплярами определенного класса, автоматически являются доступными любому классу, расположенному ниже в иерархическом дереве.

            Характеристика 7. Благодаря полиморфизму — способности подставлять во время выполнения вместо одного объекта другой, с совместимым интерфейсом, в периоде выполнения одни и те же объекты могут разными методами исполнять одни и те же запросы сообщений.

            Характеристика 8. Композиция является предпочтительной альтернативой множественному наследованию и позволяет изменять состав объектов агрегата в процессе выполнения программы.

            Характеристика 9. Структура объектно-ориентированной программы на этапе выполнения часто имеет мало общего со структурой ее исходного кода. Последняя фиксируется на этапе компиляции. Ее код состоит из классов, отношения наследования между которыми неизменны. На этапе же выполнения структура программы — быстро изменяющаяся сеть из взаимодействующих объектов. Две эти структуры почти независимы.