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

 

Архитектура программного обеспечения (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) размещения программных компонентов системы.

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

 

Похожие статьи:

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

 

Архитектура программного обеспечения (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) размещения программных компонентов системы.

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

 

Похожие статьи:

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

 

Архитектура программного обеспечения (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) размещения программных компонентов системы.

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

 

Похожие статьи:

Архитектура программных систем

⇐ Предыдущая12345678910Следующая ⇒

Архитектура ПС — это его строение как оно видно (или должно быть видно) извне, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем.(Это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними.) В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом борьбы со сложностью ПС, на котором реализуется принцип выделения относительно независимых компонентов.

Основные задачи разработки архитектуры ПС:

· выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

· определение способов взаимодействия между выделенными программными подсистемами.

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

Архитектура программной системы — есть совокупность решений относительно:

· организации программной системы;

· выбора структурных элементов, составляющих систему, и их интерфейсов;

· поведения этих элементов, специфицированного в кооперациях с другими элементами;

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

· архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способы их объединения.

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

Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения как:

· конечные пользователи,

· системные аналитики,

· руководители проекта,

· разработчики,

· тестеры,

· технические писатели,

· менеджеры

Системная архитектура управляет всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем промежутке ее жизненного цикла.

Итеративный (iterative) процесс предполагает управление потоком исполняемых версий системы.

Инкрементный (incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий системы, причем каждая следующая версия усовершенствована по сравнению с предыдущей.

---

⇐ Предыдущая12345678910Следующая ⇒

---

Дата добавления: 2015-05-08; просмотров: 358 | Нарушение авторских прав

---

Похожая информация:

Поиск на сайте:

Удивительные технологии в современной архитектуре

Современники с трудом представляют свою жизнь без электроники, компьютеров и всевозможных гаджетов. Компьютерные технологии проникли во все сферы деятельности человека, в том числе и в такие сокровенные и творческие, как искусство, прочно там обосновавшись.

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

Соединение искусства с математикой берет свое начало в Древней Греции. Именно греки вывели строгую систему пропорций, названную «греческим ордером», который позволял человеку идеально воспринимать шедевры скульптуры и архитектуры. Гениальный Леонардо да Винчи смог рассчитать параметры знаменитого золотого сечения, позволившего создать непревзойденные образцы своих творений.

Программы для проектирования домов

Антонио Сальери в произведении А. С. Пушкина утверждает, что он смог «поверить алгеброй гармонию».

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

Как измерить искусство

Формулу творчества впервые представил в 1928 году ученый-американец Биркгоф, который предложил с ее помощью рассчитывать «численное значение упорядоченности художественного произведения», определяя таким образом меру его эстетического восприятия. По его мнению, любое творение является уникальным набором информационных структур, собранным из вселенского хаоса звуков, красок, слов и пр.

Четверть века спустя европейские психологи Моль и Бензе сделали попытку применить теорию информации, рассматривая произведения искусства. Определяя культуру в виде совокупности сообщений, Моль в своей книге «Искусство и ЭВМ» исследует так называемую «норму оригинальности» математическими приемами. Его вывод очень интересен и необычен: искусство можно закодировать в универсальных знаках, так как это всего лишь эстетическая информация. А это значит, что любой шедевр можно создать с помощью ЭВМ!

Смелая теория получила поддержку в прогрессивных культурных кругах и нашла своих преданных сторонников. Известный японский модернист Исоздаки при создании проекта музея современного искусства префектуры Гунма использовал принцип информационной теории.

Читайте также:

Эра оцифрованного искусства

Невиданный размах в развитии компьютерных технологий привел к возникновению нескольких направлений информационной эстетики. Авторы культурных произведений стали широко использовать цифровые технологии, предоставляя машинам возможность технической реализации своих уникальных замыслов. Изучение компьютерного творчества — это значительная часть большой работы по созданию искусственного разума. Создание киберразума является другим направлением в разработке машины, воспроизводящей поведение живого существа с его субъективными реакциями. Архитектор Прайс еще в 1976 году создал компьютерную систему «Генератор» для удовлетворения отдельных потребностей человека, которая демонстрировала прототип искусственного интеллекта со способностью саморазвития. Впоследствии этот проект преобразился в известный «умный дом», где компьютеры, учитывая множество параметров, руководят электричеством, включают вентиляцию и отопление, открывают окна и двигают стены, увлажняют воздух и включают бытовую технику. Great London Authority — знаменитая «капля Фореста» на берегу Темзы — благодаря четким компьютерным расчетам имеет максимально энергосберегающий режим: для холодного времени применяются солнечные батареи на крыше и теплосберегающее остекление фасадов, а в жару для охлаждения помещений используются подземные источники.

Компьютерные технологии в архитектуре

Музей Гуггенхайма, построенный в 1997 году знаменитым американцем Франком Гери на севере Испании в Бильбао, стал первым образцом компьютерного проектирования. Отсюда берет свое начало эра криволинейных архитектурных форм, которые ранее невозможно было просчитать. Возведение фантастического музыкального центра в Сиэтле, необыкновенного Концертного зала Уолта Диснея в Лос-Анджелесе, здания еще одного «Гуггенхайма» в Нью-Йорке, DG Bank в Берлине — триумф цифровых технологий.

Яркие современные направления в архитектуре не смогли бы появиться без развития компьютеров.

Грег Линн оцифровывал удивительные растения на компьютере и использовал эти формы в архитектурных проектах. Элизабет Диллер и Рикардо Скофидио построили для выставки Ехро-2002 феерический дом из воды Blur Building — водяное облако высотой 20 метров, неподвижно зависшее над платформой в 120 метрах от берега и управляемое компьютером. Посетителям предлагалось пройти в удивительный «дом» по специальным мосткам, предварительно надев дождевики.

Майкл Янтцен, архитектор из Америки, создал удивительный дом-невидимку. Оригинальный видеоэкран, установленный на фасаде, полностью «растворял» дом среди окружающего пейзажа.

Авторы всех этих необычных проектов попытались разрушить традиционные представления об архитектуре. С помощью компьютерных технологий сегодня можно воплотить в жизнь абсолютно любую, самую необыкновенную и сумасшедшую идею. Понятие утопичности архитектуры уничтожено цифровыми технологиями. В современных вузах появились специальные кафедры цифровой архитектуры, где будущие специалисты учатся работать мышью, создавая уникальные проекты.

Кибернетизация современного мира является непреложным фактом. Нравится нам это или нет, но следует признать, что именно за цифровыми технологиями будущее интереснейших архитектурных произведений.