Архитектура ПО (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+ (развитие разработки Микрософт Transaction Server, MTS), разработка обработки очередей сообщений MSMQ, разработка Микрософт 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) компонентов совокупности;
размещения программных компонентов совокупности.
Разглядим, как строится любая из этих диаграмм.
Модель хранения данных
Модели данных помогают для проектирования структуры постоянных хранилищ данных, применяемых совокупностью. Они бывают двух типов:
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.