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

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

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

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

Примеры программ: редактор текстов, компилятор, программы посылки запросов от кассира и др.

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

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

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

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

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

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

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

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

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

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

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

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

IF ERRORLEVEL 2 GOTO ITEM2

IF ERRORLEVEL 1 GOTO ITEM1

……………………..

:ITEM1

……………………..

:ITEM2

……………………..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6.1. Собираемые в период выполнения программы из отдельных компонент

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6.2. Поэтапное получение новых приложений

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

ВЫВОДЫ

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

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

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

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

Контрольные вопросы

1. Что такое архитектура программ?

2. Являются ли синонимами понятия "структура" и "архитектура"?

3. В чем заключается процесс разработки архитектуры программы?

4. Как реализуется архитектура системы из отдельных программ?

5. Что такое резидентная программа?

6. Как осуществляется обмен данными через порты?

7. Перечислите принципы подхода к проектированию архитектуры системы с позиции уровней абстракции Дейкстры.

8. Почему из обычной программы создать распределенную программу легче, если она состоит из компонент?

9. Перечислите ряд ограничений, которые накладываются на компоненты.

10. Посредством чего предусматривается взаимозаменяемость компонент?