Архитектура программного обеспечения

Архитектура программного обеспечения (software architecture) представляет собой совокупность важнейших решений об организации программной системы. Она включает в себя:

· структурные элементы и их интерфейсы;

· соединения элементов во всё более крупные системы;

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

Архитектура ПО, как отмечалось ранее, является одним из важных объектов проектирования программных систем. Она имеет несколько видов, как типы чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды архитектур являются экземплярами точки зрения некоторого множества заинтересованных лиц.

Архитектурный вид состоит из двух компонентов:

· Элементы;

· Отношения между элементами.

Архитектурные виды можно разделить на три основных типа:

1. Модульные (module views), которые представляют систему как структуру из различных программных блоков.

2. Компоненты-и-коннекторы (component-and-connector views) — показывают систему как структуру из параллельно запущенных элементов (компонентов) и способов их взаимодействия (коннекторов).

3. Размещение (allocation views), отображающий размещение элементов системы во внешних средах.

Примеры модульных видов:

· Декомпозиция (decomposition view) — состоит из модулей в контексте отношения «является подмодулем»;

· Использование (uses view) — состоит из модулей в контексте отношения «использует» (т.е. один модуль использует сервисы другого);

· Уровней (layered view) — показывает структуру, в которой связанные по функциональности модули объединены в группы (уровни);

· Классов/обобщений (class/generalization view) — состоит из классов, связанных через отношения «наследуется от» и «является экземпляром».

Примеры видов компонентов-и-коннекторов:

· Процессный (process view) — состоит из процессов, соединённых операциями коммуникации, синхронизации и/или исключения;

· Параллельный (concurrency view) — состоит из компонентов и коннекторов, где коннекторы представляют собой «логические потоки»;

· Обмена данными (shared-data (repository) view) — состоит из компонентов и коннекторов, которые создают, сохраняют и получают постоянные данные;

· Клиент-серверный (client-server view) — состоит из взаимодействующих клиентов и серверов с коннектором между ними (например, протоколов и общих сообщений).

Примеры видов размещения:

· Развертывание (deployment view) — состоит из программных элементов, их размещения на физических носителях и коммуникационных элементов;

· Внедрение (implementation view) — состоит из программных элементов и их соответствия файловым структурам в различных средах (разработческой, интеграционной и т.д.);

· Распределение работы (work assignment view) — состоит из модулей и описания того, кто ответственен за внедрение каждого из них.

Несмотря на то, что было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта для моделирования программных систем в 90-е годы 20 века был создан язык UML.

Архитектурные шаблоны

Для упорядочения описания архитектур применяются архитектурные шаблоны (паттерны). Каждый шаблон решает свои задачи и имеет свои недостатки.

Наиболее распространенные типы архитектурных шаблонов:

1) Многоуровневый шаблон (Layered pattern). Система разбивается на уровни, которые на диаграмме изображаются один над другим. Каждый уровень может вызывать только уровень на 1 ниже него. Таким образом, разработку каждого уровня можно вести относительно независимо, что повышает модифицируемость системы. Недостатками данного подхода являются усложнение системы и снижение производительности.

2) Шаблон посредника (Broker pattern). Если в системе присутствует большое количество модулей, их прямое взаимодействие друг с другом становится слишком сложным. Для решения этой проблемы вводится посредник (например, шина данных), по которой модули общаются друг с другом. Таким образом, повышается функциональная совместимость модулей системы. Все недостатки вытекают из наличия посредника: он понижает производительность, его недоступность может сделать недоступной всю систему, он может стать объектом атак и узким местом системы.

3) Шаблон «Модель-Вид-Контроллер» (Model-View-Controller pattern). Т.к. требования к интерфейсу меняются чаще всего, то возникает потребность часто его модифицировать, при этом сохраняя корректное взаимодействие с данными (чтение, сохранение). Для этого в шаблоне Model-View-Controller (MVC) интерфейс отделён от данных. Такой подход позволяет менять интерфейсы, равно как и создавать их разные варианты. В MVC система разделена на следующие составляющие:

a) Модель, хранящую и обрабатывающую данные;

b) Вид, отображающий часть данных и взаимодействующий с пользователем;

c) Контроллер, являющийся посредником между видами и моделью.

Концепция MVC имеет и свои недостатки. В частности, из-за усложнения взаимодействия падает скорость работы системы.

4) Клиент-серверный шаблон (Client-Server pattern). Если есть ограниченное число ресурсов, к которым требуется ограниченный правами доступ большого числа потребителей, то удобно реализовать клиент-серверную архитектуру. Такой подход повышает масштабируемость и доступность системы. Но при этом сервер может стать узким местом системы. При его недоступности становится недоступна вся система.

В курсовом проекте необходимо использовать одну из следующих типов архитектур:

1) Монолитную, которая реализуется в виде единой программы (файла), без вспомогательных файлов и модулей;

2)
Клиент-серверную или двухзвенную, состоящую из двух частей (приложений) – клиентской и серверной. В ней сервер отвечает на клиентские запросы напрямую и в полном объеме, используя только собственные ресурсы. Общий вид такой архитектуры представлен нар рис. 5.1. Запросы к серверу (базе данных) могут быть реализованы, например, на языке MySQL.

Рис.5.1

3) Трехзвенную, которая реализуется на основе модели сервера приложений, где сетевое приложение разделено на две и более частей, каждая из которых может выполняться на отдельном компьютере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате, как показано на рис. 5.2. При этом также может быть использован язык MySQL или аналогичные средства.

Рис. 5.2

4) Сервис-ориентированную (на основе веб-cервиса), обеспечивающую распределенное взаимодействие в среде Интернет (см. рис. 5.3). Взаимодействие осуществляется посредством HTTP протокола (Hyper Text Transfer Protocol). Веб-сервис – это программа, которая реализуется на веб-сервере. В сервис-ориентированной системе выполняются следующие операции.

a) Владелец веб-сервиса размещает его на сервере, а также определяет формат запросов к сервису и его ответов.

b) Программа-потребитель веб-сервиса делает запрос на выполнение функции, предоставляемой сервисом.

c) Веб-сервис отрабатывает запрос и возвращает ответ в заявленной ранее форме.

Рис.5.3

5) Распределенную, которая использует не менее четырех уровней (см. рис.5.4).

1) представления данных (пользовательский уровень);

2) обработки данных;

3) управления данными;

4)
хранения данных.

Рис. 5.4

Уровень представления данных - единственный доступный конечному пользователю. Клиентское приложение должно обеспечивать выполнение следующих функций:

- получение данных;

- представление данных для просмотра пользователем;

- редактирование данных;

- проверка корректности введенных данных;

- сохранение выполненных изменений;

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

Функциями уровня обработки данных являются следующие:

- обработка потоков данных в соответствии с некоторыми правилами;

- взаимодействие с уровнем представления данных для получения запросов и возвращения ответов;

- взаимодействие с уровнем хранения данных для передачи запросов и получения ответов.

К функциям уровня управления данными относятся:

- управление частями распределенного приложения;

- управление соединениями и каналами связи между частями приложения;

- управление потоками данных между клиентами и серверами и между серверами;

- управление нагрузкой;

- реализация системных служб приложения.

Необходимо отметить, что часто уровень управления данными создается на основе готовых решений, поставляемых на рынок программного обеспечения различными производителями. Так, для платформы Windows, - используются разнообразные инструменты: технология COM+ (развитие технологии Microsoft Transaction Server, MTS), технология обработки очередей сообщений MSMQ, технология Microsoft BizTalk и др.

Уровень хранения данных объединяет серверы SQL и базы данных, используемые приложением. Он обеспечивает решение следующих задач:

- хранение данных в базе и поддержание их в работоспособном состоянии;

- обработка запросов уровня обработки данных и возврат результатов;

- реализация части логики распределенного приложения;

- управление распределенными базами данных при помощи административного инструментария серверов базы данных.

UML-ДИАГРАММЫ

UML (Unified Modeling Language- унифицированный язык моделирования) – это язык графического описания для объектного моделирования в области разработки программного обеспечения. Он является языком широкого профиля. Это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. Язык был создан для определения, визуализации, проектирования и документирования программных систем.

Существует 13 официальных диаграмм UML 2.0, каждая из которых представляет собой различное представление разных аспектов системы. Наиболее распространенные из них представлены на рисунке 6.1, как средства моделирования сложной системы.

Рис.6.1

Взаимосвязь между основными диаграммами UML иллюстрирует рисунок 6.2.

Рис.6.2

В курсовом проекте предлагается использовать следующие диаграммы:

1) модель хранения данных;

2) вариантов использования;

3) классов;

4) деятельности (для одного из вариантов использования);

5) последовательности действий (для одного из вариантов использования);

6) состояний основного класса программы;

7) компонентов системы;

8) размещения программных компонентов системы.

Рассмотрим, как строится каждая из этих диаграмм.