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

⇐ ПредыдущаяСтр 3 из 6Следующая ⇒

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

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

Модель хранения данных

Модели данных служат для проектирования структуры постоянных хранилищ данных, используемых системой. Они бывают двух типов:

a) Логическая и

b) Физическая.

Более подробно модели данных изучаются в рамках дисциплины «Базы данных». Здесь они будут рассмотрены кратко, в объеме, необходимом для проектирования программной системы.

В логической модели данных отображаются ключевые сущности и взаимосвязи, относящиеся к важнейшей информации, которую приложению необходимо хранить в базе данных. Она связана с моделью классов, которые используются при проектировании программы. Логическая модель отражает ключевые логические сущности и их взаимосвязи, необходимые для соблюдения требований системы к постоянному хранению данных в соответствии с общей архитектурой приложения. В теории баз данных логическую модель еще называют моделью «сущность – связь» или ER -диаграммой (от Entity – сущность и Relationships – связь).

Модель содержит совокупность сущностей, представленных в виде прямоугольников, внутри которых записывается название. Сущности связываются между собой линиями (отношениями), которые сопровождаются надписями, указывающими тип отношения: один к одному, один ко многим или многие ко многим. Типы связей и отношений иллюстрирует рисунок 6.3. На нем числом указано конкретное (начальное) значение отношения, а звездочкой – любое (много).

Рис. 6.3

Сущности могут иметь набор атрибутов (признаков объекта), одним из которых является, так называемый, ключ. Обычно связи между сущностями осуществляются по этому ключу. Он имеет одинаковые значения в каждой из них. Пример такой связи приведен на рисунке 6.4.

Рис. 6.4

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

Пример логической модели данных для объекта «Клинические записи» приведен ниже на рис. 6.5.

Рис.6.5

Модель показывает, что клинические записи включают (агрегируют) ряд блоков. При этом «минимальный набор данных» и «план лечения» могут быть включены в каждую клиническую запись в единственном экземпляре, а блоки «результаты анализов», «предписания врача», «ход лечения» могут повторяться неограниченное число раз.

Архив состоит из множества клинических записей (агрегирует клинические записи), но может быть и пустым.

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

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

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

Рис. 6.6

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

Проектировщик, в свою очередь, анализирует классы объектов и преобразует результаты анализа в структуру классов (как показано на рисунке слева). Разработчик базы данных (изображенный внизу) сотрудничает с проектировщиком системы и создает таблицы базы на основе структуры классов. При этом получают оптимальный результат.

На следующем рисунке (6.7) представлен фрагмент модели базы данных— две таблицы, соответствующие классам «пациент» и «минимальный набор данных» (см. рисунок для объекта «Клинические записи» логической модели ). Связьмежду ними обязательная, поскольку «минимальный набор данных не может существовать без «пациента».

Рис.6.7 Фрагмент модели базы данных

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

a) Ограничения, которые определяют допустимые значения данных в столбце или операции над данными:

- (ключ (PK, FK) – ограничение, определяющее тип ключа и его столбец;

- проверка (Check) – ограничение, определяющее правило контроля данных;

- уникальность (Unique) – ограничение, определяющее, что в столбце содержатся неповторяющиеся данные);

b) триггер – программа, выполняющая при определенных условиях предписанные действия с базой данных;

c) тип данных и пр.

6.2. Диаграммы вариантов использования

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

Цели построения диаграммы:

1) определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования;

2) сформулировать общие требования к функциональному проектированию системы;

3) разработать исходную концептуальную модель системы для ее последующей реализации;

4) подготовить документацию для взаимодействия разработчика системы с ее заказчиком и пользователями.

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

Таким образом, основными компонентами ДВИ являются:

a) Актеры;

b) Прецеденты;

c) Отношения.

Имя варианта использования(ВИ) начинается с большой буквы и представляется оборотом глагола или существительного, обозначающего действие (см. рис. 6.8).

Рис. 6.8

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

Пример стандартного графического изображения актера приведен на рис. 6.9.

Актер всегда находится вне системы, его внутренняя структура никак не воспринимается.

Рис. 6.9

Примеры актеров: клиент банка, банковский служащий, продавец, сотовый телефон.

Прецедент (use case – юскейс) определяет последовательность действий, которая должна быть выполнена проектируемой системой при взаимодействии ее с соответствующим актером.

Отношения устанавливают связи между актерами и прецедентами (ВИ).

Один актер может взаимодействовать с несколькими вариантами использования и наоборот.

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

Виды отношений

1) ассоциативное (отношение ассоциации, association relationship);

2) расширения (extend relationship);

3) обобщения (generalization relationship);

4) включения (include relationship).

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

Рис. 6.10

Отношение расширения определяет взаимосвязь базового варианта использования с некоторым другим вариантом, функциональное поведение которого задействуется базовым не всегда, а только при выполнении некоторых дополнительных условий. Стрелка указывает на базовый вариант использования (см. рис. 6.11).

Рис. 6.11

Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования Б (или актер А может быть обобщен до актера Б). Стрелка указывает в сторону родительского ВИ (актера). Такие отношения изображены на рис. 6.12 и 6.13.

Рис. 6.12

Рис. 6.13

Отношение включения указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта. Пример такого отношения приведен на рис. 6.14.

Рис. 6.14

Примечание (Note) в языке UML предназначено для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта. Оно представляется в виде прямоугольника с загнутым углом и может относиться к любому элементу диаграммы. Пример оформления примечания приведен на рис. 6.15.

Рис. 6.15

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

ДВИ процесса оформления заказа на покупку товара приведена на рис. 6.16, а Диаграмма прецедентов для процесса постройки дома – на рис. 6.17.

Рис. 6.16

Рис. 6.17

Диаграммы классов

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

Класс – это множество объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. На диаграмме он представляется прямоугольником, который может иметь вид, приведенный на рис. 6.18.

Рис. 6.18

Имя класса должно быть уникально. Оно должно начинаться с заглавной буквы. Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется курсив.

Атрибут - это свойство, которое является общим для всех объектов данного класса. Общий формат записи атрибутов:

< квантор видимости> < имя атрибута> [кратность]: < тип атрибута> = < исходное значение> {строка-свойство}

Квантор видимости может принимать одно из следующих значений:

« + » - атрибут с областью видимости типа общедоступный (public).

« # » - атрибут с областью видимости типа защищенный (protected).

« - » - атрибут с областью видимости типа закрытый (private).

« ~ » - атрибут с областью видимости типа пакетный (package).

Имя атрибута представляется в виде уникальной строки текста. Оно является единственным обязательным элементом в обозначении атрибута и должно начинаться со строчной буквы. По практическим соображениям записывается без пробелов.

Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. Формат:

[нижняя граница.. верхняя граница]

Примеры: [0..1], [0..*], [1..3, 5..7].

Тип атрибута - выражение, определяемое некоторым типом данных (в зависимости от языка программирования). В простейшем случае – осмысленная строка текста.

Пример:

цвет: Color

имяСотрудника[1..2]: String;

видимость: Boolean

Исходное значение служит для задания некоторого начального значения в момент создания отдельного экземпляра класса.

Пример:

цвет: Color = (255, 0, 0)

имяСотрудника[1..2]: String = ‘Иван Иванов’;

видимость: Boolean = истина

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

Пример:

заработнаяПлата: Currency = $500 {frozen}

Операции класса представляют собой некоторый сервис, который предоставляет каждый экземпляр класса или объект по требованию своих клиентов.

Правила записи операций:

< квантор видимости> < имя операции> (список параметров):
< выражение типа возвращаемого значения> {строка-свойство}

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

< вид параметра> < имя параметра>: < выражение типа> = < значение по умолчанию>

Строка-свойство служит для указания значений свойств, которые могут быть применены к данной операции. Например, для указания последовательности действий будет использована строка-свойство вида:

{concurrency = имя} ,

где имя может принимать одно из следующих значений:

sequential (последовательная),

concurrent (параллельная),

guarded (охраняемая).

Примеры операций класса

+нарисовать(форма: Многоугольник=прямоугольник, цветЗаливки: Color=(0, 0, 255));

-изменитьСчетКлиента (номерСчета: Integer): Currency;

#выдатьСообщение(): (‘Ошибка деления на ноль’).

Отношения между классами

Базовыми отношениями на диаграмме классов являются:

a) отношения ассоциации (association);

b) отношения обобщения (generalization);

c) отношения агрегации (aggregation);

d) отношения композиции (composition);

e) отношения зависимости (dependency).

Отношение ассоциации свидетельствует о наличии произвольной связи между классами. Пример такого отношения приведен на рис. 6.19.

Рис. 6.19

Отношение обобщения является отношением классификации между более общим элементом (родителем или предком) и частным или специальным элементом (дочерним или потомком). Пример такого отношения приведен на рис. 6.20.

Рис. 6.20

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

Рис. 6.21

Отношение композиции является частным случаем отношения агрегации. Части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются составные части.Пример такого отношения приведен на рис. 6.22.

Рис. 6.22

Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого элемента. Пример такого отношения приведен на рис. 6.23.

Рис. 6.23

Пакеты служат для группировки элементов модели. Их представление на диаграмме имеет вид рис. 6.24. Любой пакет владеет своими элементами. Любой элемент может принадлежать только одному пакету.

Рис. 6.24

Пример диаграммы классов приведен на рис. 6.25.

Рис. 6.25

Диаграммы деятельности

Диаграмма деятельности (активностей) напоминает привычную схему алгоритма. Она позволяет моделировать сложный жизненный цикл объекта с переходами из одного состояния (деятельности) в другое. Диаграмма использует ограниченное количество фигур, соединённых стрелками. Основные фигуры:

1. Прямоугольники с закруглениями — действия;

2. Ромбы — решения;

3. Широкие полосы — начало (разветвление) и окончание (схождение) ветвления действий;

4. Чёрный круг — начало процесса (начальное состояние);

5. Чёрный круг с обводкой — окончание процесса (конечное состояние).

Стрелки идут от начала к концу процесса и показывают последовательность переходов.

На диаграмме деятельностей можно не только показать параллельно выполняемые действия, но и указать состояния объектов (как на представлениях конечных автоматов), а также распределение ролей и т. д. Пример диаграммы для работы с сервером базы данных в сети представлен на рис. 6.26.

Для каждого объекта на диаграмме выделяется, так называемая, беговая дорожка. Она соответствует объекту или роли. На дорожке отображаются только те деятельности, за которые отвечает конкретный объект. Она является важной частью диаграммы деятельности.

Так, на рис. 6.25 активности разбросаны по трем беговым дорожкам, каждая из которых соответствует поведению одного из трех объектов - клиента, веб-сервера и сервера баз данных. Благодаря этому можно определить, каким из объектов выполняется каждая из активностей, что очень упрощает ее восприятие.

Рис. 6.26.

⇐ Предыдущая 1 234 5 6 Следующая ⇒