 |
Разработка архитектуры системы
|
|
|
|
Во время анализа требований к системе основное внимание уделялось выяснению того, что должно быть сделано, вне зависимости от того, как это сделать. На этапе разработки системы решается вопрос, как реализовать решения, принятые на этапе анализа.
Сначала разрабатывается общая структура (архитектура) системы. Архитектура системы определяет ее разбиение на модули, задает контекст, в рамках которого принимаются проектные решения на следующих этапах разработки. Приняв решения о структуре системы в целом, разработчик системы производит ее разбиение на относительно независимые в реализации части (модули), разделяя разработку между разработчиками выделенных модулей, что дает возможность расширить фронт работ, подключить к разработке системы новых исполнителей.
На этапе конструирования ПС ее разработчик должен принять следующие решения:
· определить разбиение системы на модули;
· выявить асинхронный параллелизм в системе;
· определить состав вычислительного комплекса, на котором будет работать ПС;
· распределить компоненты системы по процессорам вычислительного комплекса и независимым задачам;
· организовать управление хранилищами данных;
· организовать управление глобальными ресурсами;
· выбрать принципы реализации управления ПО;
· организовать управление пограничными ситуациями.
3.1.1. Разбиение системы на модули. Первое, что необходимо сделать, начиная этап разработки системы, определить ее разбиение на некоторое количество компонентов - модулей. Модуль не является ни объектом, ни функцией; модуль - это набор (пакет) классов и отдельных объектов, подсистем, зависимостей, операций, событий и ограничений, которые взаимосвязаны и имеют достаточно хорошо определенный и по возможности небольшой интерфейс с другими модулями. Часто модуль включает одну подсистему, являясь ее реализацией. Модуль (подсистема) обычно определяется через службы, которые он обеспечивает. Службой называется набор взаимосвязанных функций, которые совместно обеспечивают какую-либо функциональность, например, выполнение ввода-вывода, отрисовку картинок, выполнение арифметических действий. Подсистема определяет согласованный способ рассмотрения одной из сторон прикладной задачи, для решения которой разрабатывается рассматриваемая система. Например, система файлов - подсистема операционной системы; она обеспечивает набор взаимосвязанных абстрактных операций, которые в большой степени (но не полностью) независимы от абстрактных операций, обеспечиваемых другими подсистемами. Эта подсистема может быть реализована в виде отдельного модуля.
|
|
|
Как уже отмечалось, каждая подсистема имеет хорошо определенный (внешний) интерфейс с остальной частью системы (другими подсистемами). Этот интерфейс определяет форму всех взаимодействий с подсистемой и все потоки данных через ее границы, но не специфицирует внутреннюю структуру и внутреннее окружение подсистемы, а также особенности ее реализации. Поэтому каждая подсистема может разрабатываться независимо от остальных подсистем.
Подсистемы должны определяться таким образом, чтобы большая часть взаимодействий оставалась внутри подсистем, для уменьшения глобальных потоков данных и сокращения зависимостей между подсистемами. Подсистем должно быть не очень много (в пределах десятка). Некоторые подсистемы могут быть в свою очередь подразделены на подсистемы.
Две подсистемы могут взаимодействовать друг с другом либо как клиент и поставщик (клиент-сервер), либо как равноправные партнеры (сопрограммы). В первом случае клиент вызывает сервер, который выполняет некоторый запрос клиента и возвращает результат; клиент должен знать интерфейс сервера, но сервер может не знать интерфейсов клиента, так как все взаимодействия инициируются клиентом. В случае сопрограммного взаимодействия обе подсистемы вызывают друг друга. Обращение подсистемы к другой подсистеме не обязательно связано с немедленным получением ответа. Сопрограммное взаимодействие является более сложным, так как обе подсистемы должны знать интерфейсы друг друга. Поэтому нужно стараться, чтобы большая часть подсистем взаимодействовала как клиент и сервер.
|
|
|
Подсистемы (и реализующие их модули) могут образовывать в системе уровни, либо разделы.
Уровни. Уровневая система может рассматриваться как упорядоченное множество виртуальных миров, каждый из которых построен на основе понятий, поддерживаемых его подсистемами; подсистемы одного уровня обеспечивают реализацию подсистем следующего уровня. Объекты каждого уровня могут быть независимыми, хотя нередко объекты разных уровней могут соответствовать друг другу. Каждая подсистема знает о подсистемах более низких уровней и ничего не знает о более высоких уровнях. Зависимость клиент-сервер существует между более верхним (клиент) и более нижними уровнями (серверы). При этом каждый уровень может иметь свой собственный набор классов и операций. Каждый уровень реализуется через операции объектов и подсистем более нижних уровней. Уровневые архитектуры бывают двух видов: открытые и замкнутые. В замкнутой архитектуре каждый уровень строится на базе непосредственно следующего за ним уровня. Это сокращает зависимости между уровнями и упрощает внесение изменений. В открытой архитектуре каждый уровень строится на базе всех следующих за ним уровней. Это уменьшает потребность в переопределении операций на каждом уровне и приводит к более эффективному и компактному коду. Однако открытая архитектура не удовлетворяет принципу упрятывания информации, поскольку изменения в какой-либо подсистеме могут потребовать соответствующих изменений в подсистемах более высоких уровней.
Обычно лишь подсистемы самого верхнего и самого нижнего уровней могут быть выведены из постановки задачи: самый верхний уровень - это требуемая система, а самый нижний уровень - это доступные ресурсы: аппаратура, операционная система, имеющиеся библиотеки. Промежуточные уровни вводятся разработчиком системы.
|
|
|
Система с уровневой архитектурой при переносе на другую платформу требует переписывания только одного (самого нижнего) уровня. Пример системы с уровневой архитектурой представлен на рис. 3.1.
Рис. 3.1. Пример системы с уровневой архитектурой
Разделы. Разделы подразделяют систему на несколько независимых или слабо связанных модулей (подсистем), каждая из которых обеспечивает один из видов услуг. Например, операционная система компьютера включает систему файлов, управление процессами, управление виртуальной памятью и управление устройствами.
Обычно система подразделяется на модули (подсистемы) с использованием обоих способов разбиения в самых разных комбинациях: уровни делятся на разделы, разделы содержат в себе уровни. Пример такой структуры системы показан на рис. 3.2.
Рис. 3.2. Типичная структура системы
Рис. 3.4. Топология звезды
Топология системы. Когда все модули и подсистемы всех уровней названы, необходимо показать информационные потоки между модулями и подсистемами, построив ДПД (примеры см. в п. 3.1.8). Это позволит понять топологию системы. Топология системы определяется совокупностью потоков информации в системе; например, у компилятора конвейерная топология (рис. 3.3), можно представить себе топологию звезды (рис. 3.4) и т.п.; нужно стремиться, чтобы топология системы была как можно проще.
3.1.2. Выявление асинхронного параллелизма. В анализируемой модели, как и в реальном мире и в программном обеспечении все объекты независимы и должны работать асинхронно. Однако в реализации не все объекты должны работать независимо и асинхронно, так как несколько объектов может выполняться на одном процессоре, если известно, что они не могут быть одновременно активными. Одна из важнейших целей разработки системы выяснить, какие объекты должны быть активными одновременно (параллельно), а какие бывают активными только в разное время. Эти последние объекты могут быть связаны в одну нить управления (задачу).
|
|
|
Для определения асинхронности (параллельного существования) объектов используется динамическая модель. Два объекта являются существенно асинхронными, если они могут получать события в одно и то же время, не взаимодействуя друг с другом. Если события не синхронизируются, такие объекты не могут быть связаны в одну нить управления.
От асинхронных объектов нужно отличать полностью независимые объекты, которые не только выполняются независимо, но и не обмениваются данными в процессе своей работы. Полностью независимые системы удобны тем, что их можно поместить на разные аппаратные устройства, исключив при этом коммуникационные затраты.
Асинхронные объекты могут выполняться и на одном устройстве (процессоре), если оно имеет систему прерываний и поддерживает режим разделения времени. Во многих случаях необходимость выполнять объекты на разных устройствах следует из постановки задачи. Так, например, в задаче о банковской сети заранее ясно, на каких устройствах должны работать соответствующие объекты.
3.1.3. Распределение модулей и подсистем по процессорам и задачам. Каждый асинхронный (независимый) объект (модуль или подсистема) должен быть приписан к одному из устройств аппаратуры: универсальному процессору или специализированному функциональному устройству. Разработчик системы должен:
· оценить требуемую производительность и требуемые ресурсы;
· выбрать способ реализации подсистем (аппаратный или программный);
· распределить программные подсистемы по процессорам, стремясь удовлетворить их требования по производительности и в то же время сократить межпроцессорные коммуникации.
Оценка требуемых ресурсов. Решение использовать несколько процессоров обычно бывает связано с потребностью иметь более высокую производительность, чем производительность одного процессора. Количество требуемых процессоров зависит от объема вычислений и производительности компьютера. Разработчик системы может оценить требуемую производительность процессоров, вычисляя постоянную нагрузку как произведение количества транзакций в секунду на время выполнения одной транзакции (в примере с банковской сетью транзакция это проводка). Такая оценка не учитывает накладных расходов, связанных со случайными изменениями нагрузки и некоторыми другими факторами. Ее следует уточнить.
Замена программ аппаратурой. Аппаратуру следует рассматривать как неизменяемое тщательно оптимизированное программное обеспечение. Каждое устройство может рассматриваться как объект, который работает параллельно с другими объектами. Разработчик может принять решение о замене некоторых объектов подходящими аппаратными устройствами. Обычно такое решение принимается по следующим причинам:
|
|
|
· требуемые устройства легко доступны; в наше время легче купить процессор с плавающей арифметикой, чем реализовать соответствующую библиотеку;
· требуется более высокая производительность, чем производительность имеющихся процессоров, а производительность специализированных устройств всегда выше.
Распределение модулей и подсистем по процессорам. При распределении модулей и подсистем по процессорам следует иметь в виду следующее:
· некоторые задачи нужно выполнять на определенных устройствах; например, обработку банковской карточки следует выполнять на ATM;
· время ответа или скорость информационного потока превышает пропускную способность канала между процессором и программой; например, высокоскоростные графические устройства требуют спаренных контроллеров;
· скорости вычислений слишком высоки для одного процессора, и задачи нужно разместить на нескольких процессорах; подсистемы, которые часто взаимодействуют, нужно поместить на одном процессоре.
3.1.4. Управление хранилищами данных. Внутренние и внешние хранилища данных являются четкими точками раздела между подсистемами с хорошо определенными интерфейсами. В качестве хранилищ данных могут использоваться БД, файлы и другие структуры данных, размещенные во внешней или основной памяти. Выбор вида хранилища данных зависит от ситуации.
В БД обычно размещают данные, удовлетворяющие одному из следующих условий:
· данные, для которых требуется доступ на высоком уровне детализации со стороны многих пользователей;
· данные, которые могут эффективно управляться командами СУБД;
· данные, которые должны переноситься на многие платформы;
· данные, для которых требуется доступ со стороны нескольких прикладных программ.
В файлах размещают данные, удовлетворяющие одному из следующих условий:
· данные, которых много, но которые плохо поддаются структуризации;
· данные с низкой информационной плотностью (например, дампы);
· "сырые" данные, подготавливаемые для БД;
· "летучие" данные, которые хранятся короткое время, а потом удаляются.
3.1.5. Управление глобальными ресурсами. Необходимо определить глобальные ресурсы и разработать механизмы управления доступом к ним. Глобальными ресурсами могут быть: процессоры, устройства внешней памяти, экран рабочей станции, логические имена (идентификаторы объектов, имена файлов, имена классов), доступ к БД и т.п.
3.1.6. Реализация управления программным обеспечением. Во время анализа все взаимодействия представляются в виде событий. Управление аппаратурой соответствует этой модели, но необходимо выбрать метод управления программным обеспечением системы. Существует два класса методов управления программным обеспечением: методы внешнего управления и методы внутреннего управления.
Известны три метода внешнего управления:
1. последовательное управление процедурами,
2. последовательное управление событиями,
3. параллельное асинхронное управление.
При последовательном управлении процедурами в каждый момент времени действует одна из процедур; это наиболее легко реализуемый способ управления. При последовательном управлении событиями управлением занимается монитор (диспетчер). При параллельном асинхронном управлении этим заведует несколько управляющих объектов (мониторов).
Внутреннее управление связано с потоками управления в процессах. Оно существует только в реализации и потому не является только последовательным или параллельным. В отличие от внешних событий, внутренние передачи управления, как например, вызовы процедур или обращения к параллельным задачам контролируются программой и могут быть структурированы в случае необходимости.
Здесь мы рассматриваем, в основном, процедурное программирование, но, конечно, возможны и другие парадигмы, как например, логические ПС, функциональные ПС и другие виды непроцедурных ПС. В этом курсе такие системы не рассматриваются.
3.1.7. Пограничные ситуации. Необходимо предусмотреть поведение каждого объекта и всей системы в пограничных ситуациях: инициализации, терминации и обвале.
Инициализация. Перед тем, как начать работать, система (объект) должна быть приведена в фиксированное начальное состояние: должны быть проинициализированы все константы, начальные значения глобальных переменных и параметров, задачи и, возможно, сама иерархия классов. Во время инициализации, как правило, бывает доступна лишь часть возможностей системы.
Терминация состоит в освобождении всех внешних ресурсов, занятых задачами системы.
Обвал - это незапланированная терминация системы. Обвал может возникнуть в результате ошибок пользователя, нехватки ресурсов, или внешней аварии. Причиной обвала могут быть и ошибки в программном обеспечении системы.
3.1.8. Обзор архитектур прикладных систем. Существует несколько типов архитектур, обычно используемых в существующих системах. Каждая из них хорошо подходит к определенному типу систем. Проектируя систему одного из нижеперечисленных типов, имеет смысл использовать соответствующую архитектуру. Мы рассмотрим следующие типы систем:
· системы пакетной обработки - обработка данных производится один раз для каждого набора входных данных;
· системы непрерывной обработки - обработка данных производится непрерывно над сменяющимися входными данными (рис. 3.5);
· системы с интерактивным интерфейсом - системы, управляемые внешними воздействиями (рис. 3.6);
· системы динамического моделирования - системы, моделирующие поведение объектов внешнего мира;
· системы реального времени - системы, в которых преобладают строгие временные ограничения;
· системы управления транзакциями - системы, обеспечивающие сортировку и обновление данных; имеют коллективный доступ;
· типичной системой управления транзакциями является СУБД.
При разработке системы пакетной обработки необходимо выполнить следующие шаги:
· Разбиваем полное преобразование на фазы, каждая из которых выполняет некоторую часть преобразования; система описывается диаграммой потока данных, которая строится при разработке функциональной модели.
· Определяем классы промежуточных объектов между каждой парой последовательных фаз; каждая фаза знает об объектах, расположенных на объектной диаграмме до и после нее (эти объекты представляют соответственно входные и выходные данные фазы).
· Составляем объектную модель каждой фазы (она имеет такую же структуру, что и модель всей системы в целом: фаза разбивается на подфазы); разрабатываем каждую подфазу.
Рис. 3.5. Система непрерывной обработки: машинная графика
При разработке системы непрерывной обработки необходимо выполнить следующие шаги:
· Строим диаграмму потока данных; активные объекты в ее начале и в конце соответствуют структурам данных, значения которых непрерывно изменяются; хранилища данных, связанные с ее внутренними фазами, отражают параметры, которые влияют на зависимость между входными и выходными данными фазы.
· Определяем классы промежуточных объектов между каждой парой последовательных фаз; каждая фаза знает об объектах, расположенных на объектной диаграмме до и после нее (эти объекты представляют соответственно входные и выходные данные фазы).
· Представляем каждую фазу как последовательность изменений значений элементов выходной структуры данных в зависимости от значений элементов входной структуры данных и значений, получаемых из хранилища данных (значение выходной структуры данных формируется по частям).
Рис. 3.6. Система с интерактивным интерфейсом: ATM
При разработке системы с интерактивным интерфейсом необходимо выполнить следующие шаги:
· Выделяем объекты, формирующие интерфейс.
· Если есть возможность, используем готовые объекты для организации взаимодействия (например, для организации взаимодействия системы с пользователем через экран дисплея можно использовать библиотеку системы X-Window, обеспечивающую работу с меню, формами, кнопками и т.п.).
· Структуру программы определяем по ее динамической модели; для реализации интерактивного интерфейса используем параллельное управление (многозадачный режим) или механизм событий (прерывания), а не процедурное управление, когда время между выводом очередного сообщения пользователю и его ответом система проводит в режиме ожидания.
· Из множества событий выделяем физические (аппаратные, простые) события и стараемся при организации взаимодействия использовать в первую очередь их.
При разработке системы динамического моделирования необходимо выполнить следующие шаги:
· По объектной модели определяем активные объекты; эти объекты имеют атрибуты с периодически обновляемыми значениями.
· Определяем дискретные события; такие события соответствуют дискретным взаимодействиям объекта (например, включение питания) и реализуются как операции объекта.
· Определяем непрерывные зависимости (например, зависимости атрибутов от времени); значения таких атрибутов должны периодически обновляться в соответствии с зависимостью.
· Моделирование управляется объектами, отслеживающими временные циклы последовательностей событий.
Разработка системы реального времени аналогична разработке системы с интерактивным интерфейсом.
При разработке системы управления транзакциями необходимо выполнить следующие шаги:
· Отображаем объектную модель на БД.
· Определяем асинхронно работающие устройства и ресурсы с асинхронным доступом; в случае необходимости определяем новые классы.
· Определяем набор ресурсов (в том числе - структур данных), к которым необходим доступ во время транзакции (участники транзакции).
· Разрабатываем параллельное управление транзакциями; системе может понадобиться несколько раз повторить неудачную транзакцию прежде, чем выдать отказ.
|
|
|
