И. Соммервилл - Инженерия программного обеспечения (1133538), страница 53
Текст из файла (страница 53)
Проектирование 3. Багояаснасагь. В этом случае архитектуру следует спроектировать так, чтобы за все операции, влияющие на безопасность системы, отвечало как можно меньше подсистем. Такой подход позволяет снизить стоимость разработки и решает проблему проверки надежности. 4. Надежность В этом случае следует разработать архитектуру с включением избыточных компонентов, чтобы можно было заменять и обновлять их, не прерывая работу системы. Архитектуры отказоустойчивых систем с высокой работоспособностью рассматриваются в главе 18. 5.
Иэбсжво сопровождения. В этом случае архитектуру системы следует проектировать на уровне мелких структурных компонентов, которые можно легко изменять. Программы, создающие данные, должны быть отделены от программ, использующих эти данные. Следует также избегать структуры совместного использования данных. Очевидно, что некоторые из перечисленных архитектур противоречат друг другу. Например, для того чтобы повысить производительность, необходимо использовать крупномодульные компоненты, в то же время сопровождение системы намного упрощается, если она состоит из мелких структурных компонентов.
Если необходимо учесть оба тре бования, следует искать компромиссное решение. Ранее уже было сказано, что один из способов решения подобных проблем состоит в применении различных архитектурных моделей для разных частей системы. 10.1. Структурирование системы На первом этапе процесса проектирования архитектуры система разбивается на несколько взаимодействующих подсистем. На самом абстрактном уровне архитектуру системы можно изобразить графически с помощью блоксхемы, в которой отдельные подсистемы представлены отдельными блоками. Если подсистему также можно разбить на несколько частей, на диаграмме эти части изображаются прямоугольниками внутри больших блоков.
Потоки данных и/или потоки управления между подсистемами обозначается стрелками. Такая блок. схема дает общее представление о структуре системы. На рис. 10.1 представлена структурная модель архитектуры для системы управления автоматической упаковкой различных типов объектов. Она состоит из нескольких частей. Подсистема наблюдения изучает объекты на конвейере, определяет тип объекта и выбирает для него соответствующий тип упаковки. Затем объекты снимаются с конвейера, упаковываются н помещаются на другой конвейер. Примеры других архитектур приведены на рис. 2.2 и 2лх Басс (Ваза, [29]) считает, что подобные блоксхемы являются бесполезными представлениями системной архитектуры, поскольку из них нельзя ничего узнать ни о природе взаимоотношений между компонентами системы, ни об их свойствах.
С точки зрения разработчика программного обеспечения. это абсолютно верно. Однако такие модели оказываются эффективными на этапе предварительного проектирования системы. Эта модель не перегружена деталями, с ее помощью удобно представить структуру системы. В структурной модели определены все основные подсистемы, которые можно разрабатывать независимо от остальных подсистем, следовательно, руководитель проекта может распреде. лить разработку этих подсистем между различнымн исполнителями.
Конечно, для представления архитектуры используются не только блоксхемы, однако подобное представление системы не менее полезно, чем другие архитектурные модели. 10. Архитектурное проектирование 209 Рис. 10.1. Блоксхема сипаемм уараоления аетомати соской уааеоокой Конечно, можно разрабатывать более детализированные модели структуры, в которых было бы показано, как именно подсистемы разделяют данные и как взаимодействуют др> г с другом.
В этом разделе рассматриваются три стандартные модели, а именно: модель репозитория, модель клиентсссервер и модель абстрактной машины. 10.1.1. Модель репозитория Для того чтобы подсистемы, составллющие систему, работали эффекгивнее, между ними должен идти обмен информацией. Обмен можно организовать двумя способами. 1. Все совместно используемые данные хранятся в центральной базе данньпс, доступ. ной всем подсистемам.
Модель системы, основанная на совместном использовании базы данных, часто называют маделью реаалиинуия. 2. Каждая подсистема имеет собственную базу данных. Взаимообмен данными между подсистемами происходит посредством передачи сообщений.
Большинство систем, обрабатывающих большие объемы данных, организованы вокруг совместно используемой базы данных, или репозитория. Поэтому такал модель подойдет к приложениям, в которых данные создаются в одной подсистеме, а используются в дру. той. Примерами могут служить системы управления информацией, системы автоматнче. ского проектирования и САЗЕ-средства. На рис. 10.2 представлен пример архитектуры интегрированного набора САЗЕ- инструментов, основанный на совместно используемом репозитарии.
Считается, что для САЗЕюредств первый совместно используемый репозиторий был разработан в начале 1970-х годов английской компанией 1СЕ в процессе создания своей операционной системы 12341. Широкую известность эта модель получила после того, как была применена для поддержки разработки систем, написанных на языке Ада. С тех пор многие САЯЕ. средства разрабатываются с использованием общего репозитория. 2! О г4асть 1П. Проектирование Рис. 10.2.
Арли тек лгу~я интегрировпнпого япбп~п СдзЕсргдстп Совместно используемые репозитории имеют как преимущества, так и недостатки. Е Очевидно, что совместное использование больших объемов данных эффективно, поскольку не требуется передавать данные нз одной подсистемы в другие. 2. С другой стороны, подсистемы должны быть согласованы с моделью репозитория данных. Это всегда приводит к необходимости компромисса между требованиями, предъявляемыми к каждой подсистеме.
Компромиссное решение может понизить их производительность. Если форматы данных новых подсистем не подходят под согласованную модель представления данных, интегрировать такие подсистемы сложно или невозможно. 5. Подсистемам, в которых создаются данные, не нужно знать, как эти данные используются в других подсистемах. 4. Поскольку в соответствии с согласованной моделью данных генерирукггся болыние объемы информации, модерниэация таких систем проблематична.
Перевод системы на новую модель данных будет дарогостошцим и сложным, а порой даже невозмолагым. 5. В системах с репозиторием такис средства, как резервное копирование, обеспечение безопасности, управление доступом и восстановление данных, централизованы, поскольку входят в систему управления репоэиторием. Эти средства выполняют только свои основные операции и пс занимаются другими вопросами. 6. С другой стороны, к разным подсистемам предъявляются разные требования, касающиеся безопасности, восстановления и резервирования данных.
В модели репозитория ко всем подсистемам применяется одинаковая политика. 7. Модель совместного использования репозитория прозрачна: если новые подсистемы совместимы с согласованной моделью данных, их можно непосредственно интегрировать в систему. 8. Однако сложно разместить репознторий на нескольких машинах, поскольку могут возникнуть проблемы, свя ванн ыс с избыточностью и нарушением целоспюсти данных. В рассматриваемой модели репоэиторий является пассивным элементом, а управление им возложено на подсистемы, использующие данные из репозитория. Для систем искусствешюго интеллекта разработан альтернативный подход. Он основан на модели "рабочей области", которая инициирует подсистемы тогда, когда конкретные данные становятся доступными.
Такой подход применим к системам, в которых форма данных хорошо структурирована. Эта модель обсуждается в работе [255]. 10. Архитектурное проектирование 211 10.1.2. Модель клиент/сервер Модель архитектуры клиент/сервер — это модель распределенной системы, в которой показано распределение данных и процессов мехщу несколькими процессорами.
Модель вкаочаст три основных компонента. 1. Набор автономных серверов, предоставляющих сервисы другим подсистемам. Например, сервер печати, который предоставляет услуги печати, файловые серверы, предоставляющие сервисы управления файлами, и сервер-компилятор, который предлагает сервисы по компилированию исходных кодов программ. 2. Набор клиентов, которые вызывают сервисы, предоставляемые серверами. В кон. тексте системы клиенты являются обычными подсистемами. Допускается парал. лельное выполнение нескольких экземпляров клиентской программы. 3.
Сеть, посредством которой клиенты получают доступ к сервисам. В принципе нет никакого запрета нато, чтобы клиенты и серверы запускались на одной машине. На практике, однако, модель клиент/сервер в такой ситуации не используется. Клиенты должны знать имена доступных серверов и сервисов, которые они предоставляют. В то же время серверам не нужно знать ни имена клиентов, нн их количество. Клиенты получают доступ к сервисам, предоставляемым сервером, посредством удаленного вызова процедур. Рис. 10.3.
Архитектура бибаиотпеч ной систлчи фальков и фотографий Пример системы, организованной по типу модели клиент/сервер, показан на рис. 10.3. Это многопользовательская гипертекстовая система, предназпаченнал для поддержки библиотек фильмов и фотографий. В ней содержится несколько серверов, которые размещают различные типы медиафайлов и управляют нмн.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
