Технологии программирования
Шрифт:
Подход к проектированию архитектуры системы на основе абстрактных машин Дейкстры можно пояснить на следующем примере.
Процессор фирмы "Intel" может лишь выполнять операции арифметики и, осуществляя сравнения двух величин, может выполнять команды перехода на команды в заданных адресах памяти. Программировать такую ЭВМ можно в виде прямой записи двоичных команд.
ЭВМ IBM PC имеет специальное постоянное запоминающее устройство с программами BIOS. После установки BIOS получается машина с дополнительными командами загрузки программы с дисков, чтения информации из любого сектора дисков, чтения символа с клавиатуры, вывода информации на экран и т. д. Благодаря прерываниям BIOS, становится возможным использование
После установки операционной системы MS DOS на машину IBM PC получается машина с новой поддержкой данных в виде файлов и с новыми командами работы над файлами и директориями (копирования, удаления и т. д.). Новая машина может выполнять операции над вещественными числами с плавающей точкой. Появляются команды запуска выполняемых файлов и другие новые команды.
После установки операционной системы MS Windows 3.1 (при установке операционной системы MS Windows 95 одновременно устанавливается и MS DOS) появляются новые команды управления окнами для работы специалистов "со столами, заваленными бумагами". Появляется возможность одновременного запуска разных программ в разных окнах с возможностью междуоконного обмена информацией.
После установки программного комплекса Microsoft Office появляются среды и команды работы над документами, расчетными таблицами и т. д.
6.6. СОМ — ТЕХНОЛОГИЯ РАЗРАБОТКИ РАЗВИВАЮЩИХСЯ И РАССРЕДОТОЧЕННЫХ КОМПЛЕКСОВ ПРОГРАММ
СОМ — Component Object Model (модель компонентных объектов) — это спецификация метода создания компонент и построения из них программ.
В литературных источниках можно найти множество теорий и предложений по так называемой технологии эволюционного программирования. Однако до СОМ практически неизвестны удачные примеры разработки эволюционирующих во времени программ. Это объясняется невозможностью однозначного предсказания людьми будущего. Поэтому советы типа "предусмотри то-то в программе для будущего развития" оказывались бессмысленными из-за того, что в ходе сопровождения выяснялась потребность в каких-то иных доработках, но не в априори заложенных.
Традиционно программа проектировалась из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое.
Компоненты СОМ представляют собой исполняемый код, обычно распространяемый в виде динамически компонуемых библиотек (DLL). Компоненты СОМ подключаются друг к другу динамически.
Разработка программ из компонентов так называемых приложений компонентной архитектуры происходит совершенно иначе. С появлением СОМ единого целого больше нет. Программы состоят из отдельных компонент. Компонента поставляется пользователю как двоичный код, скомпилированный, скомпонованный и готовый к использованию. Доступ к этому коду осуществляется через документированный точно интерфейс. Во время выполнения компоненты подключаются к другим компонентам, формируя программу.
СОМ — это инструмент разработки развивающихся и рассредоточенных (многомашинных) комплексов программ, основанная на модели компонентных объектов.
Главное в СОМ — следование стандартным спецификациям интерфейса компонент. Однажды принятый стандарт спецификаций интерфейса никогда не изменяется. Однако после разработки нового стандарта новые компоненты сами будут опознавать старый и новый стандарты. После замены некоторого числа компонент программа вдруг заработает по-новому!
По мере развития программы, компоненты, составляющие программу, могут заменяться новыми. Программа более не является статичной, обреченной устареть еще до выхода в свет. Вместо этого она постепенно эволюционирует с заменой старых компонент новыми. Из существующих компонент легко создать и абсолютно новые программы.
Пользователи
Рис. 6.1. Собираемые в период выполнения программы из отдельных компонент
Один из самых многообещающих аспектов внедрения компонентной архитектуры — быстрая разработка программ. Вы сможете выбирать компоненты из библиотеки и составлять из них, как из деталей конструктора, цельные приложения методом морфологического синтеза! Практически все продаваемые сегодня приложения Microsoft используют СОМ. Технология ActiveX этой фирмы построена на основе компонент СОМ. Программисты на Visual Basic, C++, Delphi и Java могут воспользоваться управляющими элементами ActiveX для ускорения разработки своих приложений и страниц Web. Конечно, каждому приложению по-прежнему будут нужны и некоторые специализированные компоненты, но для построения простых приложений можно обойтись стандартными.
Создать из обычной программы распределенную программу легче, если эта обычная программа состоит из компонент. Во-первых, она уже разделена на функциональные части, которые могут располагаться вдали друг от друга. Во-вторых, поскольку компоненты заменяемы, вместо некоторой компоненты можно подставить другую, единственной задачей которой будет обеспечивать связь с удаленной компонентой.
Преимущества использования компонент непосредственно вытекают из способности последних подключаться к приложению и отключаться от него. Для этого компоненты должны удовлетворять двум требованиям. Во-первых, они должны компоноваться динамически. Во-вторых, должны скрывать (или инкапсулировать) детали своей реализации.
Чтобы понять, как это связано с инкапсуляцией, необходимо определить некоторые термины. Программа или компонента, использующая другую компоненту, называется клиентом (client). Клиент подсоединяется к компоненте через интерфейс (interface). Если компонента изменяется без изменения интерфейса, то изменений в клиенте не потребуется. Аналогично если клиент изменяется без изменения интерфейса, то нет необходимости изменять компоненту. Однако если изменение либо клиента, либо компоненты вызывает изменение интерфейса, то и другую сторону интерфейса также необходимо изменить.
Таким образом, для того чтобы воспользоваться преимуществами динамической компоновки, компоненты и клиенты должны стараться не изменять свои интерфейсы и быть инкапсулирующими. Детали реализации клиента или компоненты не должны отражаться в интерфейсе. Чем надежнее интерфейс изолирован от реализации, тем менее вероятно, что он изменится при модификации клиента или компоненты. Если интерфейс не изменяется, то изменение компоненты оказывает лишь незначительное влияние на приложение в целом.