И. Соммервилл - Инженерия программного обеспечения (1133538), страница 54
Текст из файла (страница 54)
Видеофайлы требуется передавать быстро и синхронно, по с относительно малым разрешением. Опи могут храниться в сжатом состоянии. Фотографии должны персдаватьсл с высоким разрешением. Каталоги лолжны обеспечивать работу с множеством запросов и поддерживать связи с использованием гипертекстовой системы. Здесь клиентская программа является просто интегрированным интерфейсом пользователя. Подход клиент/сервер можно использовать при реализации систем.
основанных па репо. знтории, который поддерживается как сервер системы. Подсистемы, имеющие доступ к репо. знторию, являютсл клиентами. Но обычно каждал подсистема управляет собственными данными. Во времл работы серверы н клиенты обмениваются дапнымн, однако при обмене боль- 212 Часть Ш. Проектирование шими объемами данных могут возникнуть проблемы, связанные с пропускной способностью сети. г)раааа, с развитием все более быстрых сетей эта проблема теряет свое значение. Наиболее важное преимущество модели клиент/сервер состоит в том, что она является распределенной архитектурой. Ее эффективно испольэовать в сетевых системах с множеством распределенных процессоров.
В систему легко добавип новый сервер и интегрировать его с осталъной частью системы или же обновить серверы, не воздействуя на другие части системы. В главе 11 архитектуры распределенных систем рассматриваются более подробно. 10.1.3. Модель абстрактной машины Модель архитектуры абстрактной машины (иногда называемая многоуровневой моде лью) моделирует взаимодействие подсистем.
Она организует систему в виде набора уровней, каждый из которых предоставляет свои сервисы. Каждый уровень определяет лбст)глквгную машину, машинный язык которой (сервисы, предоставляемые уровнем) использу. ется для реализации следующего уровня абстрактной машины. Например, наиболее распространенный способ реализации языка программирования состоит в определении идеальной "языковой машины" и компилировании программ, написанных на данном языке, в код этой машины. На следующем шаге трансляции код абстрактной машины конвертируется в реальный машинный код. Хорошо известным примером такого похода может служить модель Оя!г сетевых протоколов [ЯЬ2), обсуждаемая в разделе 10.4.
Другим примером является трехуровневая мо. дель среды программирования на языке Ада [66]. На рис. 10.4 изображена подобная мо. дель и показано, каке помощью модели абстрактной машины можно представить систему администрирования версий. Система администрирования версий основана на управлении версиями объектов и ггра доставляет средства для полного управления конфигурацией системы (см.
главу 29). Для поддержки средств управления конфигурацией используется система администрирования объектов, поддерживающая систему базы данных и сервисы управления объектами. И свою очередь, в системе баэ данных поддерживаются различные сервисы, например управления транзакциями, отката назад, восстановления и управления доступом.
Для управления баэамн данных используются средства основной операционной системы и ее файловая система. Рнс. 10.4. Модель лбапрлктной млшпнм для системы и дми нкап ри)сования всрсгсй ОЭГ (О(ни $)нат гпксатнсагтг - юапмодсйсоюнс отк)гнтык аиоюм)- мсжгэгнл(годнло гг)Мс)гамма агин. до(гтюлзип ойнгнл доннами между канпьюннутмнн скансмпми нл оснввс амиу~ювнюой модссн ггьотсновов пс)гсдггчи донн нк в откугнвгнк агстсмвк. Этл людссь гг)гсднаженл д)сждунлфодной овсвггпслапаг по стлггдп)гтн.
гвэнн )ЭО Опгспгвйопл! ШандапЬ Огяпггпл!юн). - Прим. рел. 10. Архитектурное проектирование 212 Многоуровневый подход обеспечивает пошаговое развитие систем — при разработке какого-либо уровня предоставляемые им сервисы становятся доступны пользователям.
Кроме того, такая архитектура легко изменяема и переносима на разные платформы. Изменение интерфейса любого уровня повлияет только на смежный уровень. Так как в мно. гоуровневых системах зависимости от машинной платформы локализованы на внутренних уровнях, такие системы можно реализовать на других платформах, поскольку потребуется изменить только самые внугреннис уровни. Недостатком многоуровневого подхода является довольно сложная структура системы.
Основные средства, такие как управление файлами, необходимыс всем абстрактным машинам. предоставляются внутренними уровнями. Поэтому сервисам, запрашиваемым пользователем, возможно, потребуется доступ к внутренним уровням абстрактной машины. Такая ситуация приводит к разрушению модели, так как внешний уровень зависит не только от предшествующего ему уровня, но и от более низких уровней. 10.2.
Модели управления В модели структуры системы показаны все подсистемы, иэ которых она состоит. Для того чтобы подсистемы функционировали как единое целое, необходиио управлять ими. В структурных моделях нет (и нс должно быть) никакой информации по управлению. Однако разработчик архитектуры должен организовать подсистемы согласно некоторой молели управления, которая дополняла бы имеющуюся модель структуры.
В моделлх управления на уровне архитектуры проектируется поток управления между подсистемами. Можно выделить два основных типа управления в программных системах. 1. Цгнэцкыкэогвнноеун1заэление Одна из подсистем полностью огвсчаег за управление, запускает и завершает работу остальных подсистем. Управление от первой подсистемы может перейти к другой подсистеме, однако потом обязательно возвращается к первой. 2. Уиравление, ооыаанкое ка сабмлчиях. Здесь вместо одной подсистемы, ответственной за управление, на внешние события. может отвечать любая подсистема.
События, на которые реагирует система, могут происходить либо в других подсистемах, либо во внешнем окружении системы. Модель управления дополняет струкгурные модели. Все описанные ранее структурные модели можно реализовать с помощью централизованного управления или управления, основанного на событиях. 10.2.1. Централизованное управление В модели централизованного управления одна из систем назначается главной и управляет работой других подсистем.
Такие модели можно разбить на два класса, в зависимости от то. го, последовательно или параллельно реализовано выполнение управляемых подсистем. 1. Модель амэовпвоаврпэкь Это известная модель организации вызова программных процедур "сверху вниз", в которой управление начинается на вершине иерархии процедур и через вызовы передастся на более нижние уровни иерархии. Данная модель применима только в последовательных системах. 2. Модель дксгмтчфа. Применяетсл в параллельных системах. Один системный компонент назначается диспетчером и управляет запуском, завершением и коордипиро. ванием других процессов системы.
Процесс (выполняемая подсистема или молуль) 214 з1асть 1П. Проектирование может протекать параллельно с другими процессами. Модель такого типа приме. пима также в последовательных системах, где управляющая программа вызывает отдельные подсистемы в зависимости от значений некоторых переиенных состояния.
Обычно такое управление реализуется через оператор сазе. Модель вызова-возврата представлена на рис. 10.5. Из главной программы можно вызвать подпрограммы 1, 2 и 3, нз подпрограммы 1 — подпрограмиы 1.1 и 1.2, из подпрограммы 3 — подпрограммы 3.1 и 3.2 и т.д. Такая модель выполнения подпрограмм ив явля. вшгя структурной — подпрограмма 1.1 не обязательно является частью подпрограммы 1. Подпрогравма !.! Подпро~рамма !.2 Подпрограмма 3.! Подпрограмма 2.2 Ркс. 10.5.
Модель вьиввл.возврппш Подобная модель встроена в языки программирования Ада, Риса! и С. Управление переходит от программы. расположенной на самон верхнем уровне иерархии, к подпро. грамме более нижнего уровня. Затем происходит возврат управления в точку вызова под. программы. За управление отвечает та подпрограмма. которая выполняетсл в текущий момент; она может либо вызывать другие подпрограммы, либо вернуть управление вы.
звавшей се подпрограмме. Несовершенство данного стиля программирования при воз. врате к определенной точке в программе очевидно. Модель вызова-возврата можно использовать па уровне модулей для управления функциями и объелтами. Подпрограммы в языке програимирования, которые вызываются из других подпрограмм, являются естественно функциональными. Однако во многих объ. ектигзориентированных системах операции в объектах (ьгетоды) реализованы в виде процедур илн функций.
Например, объект ) ага запрашивает сервис из другого объекта посрелством вызова соответствующего метода. Жесткая и ограниченная природа модели вызова-возврата явлпется одновременно и преимушеством и недостатком. Преимущества модели проявляются в относительно про. етом анализе потоков управления, а также при выборе системы, отвечающей за конкрсзный ввод данных. Недостаток модели, как вы узнаете из главы 18, состоит в сложной об. работке исключительных ситуаций. 1!а рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
