Слайд 2
Лекция 4 Архитектура ПО
Определение архитектуры ПО
Архитектурные проектные решения,
ключевые понятия
Классы архитектур ПО
Документирование архитектуры, множественность точек зрения
Цели:
Слайд 3
Архитектура ПО: Структура ПО
Продуктовая линия
Система /продукт
Подсистемы /модули
Пакеты
Классы/объекты
Методы
Исходный код
Высший
уровень абстракции
Наинизший
уровень абстракции
Слайд 4
Архитектура ПО
Определение 1: Архитектура ПО - это внутренняя
структура программного продукта (компоненты и их связи)
основы пользовательского
интерфейса продукта, а также
главные знания и решения, являющиеся инструментом
разработки и управления проектом.
Определение 2: Архитектура ПО = набор решений
высокого уровня, которые определяют какими должны
быть ключевые элементы системы и их связи друг с
другом.
Т.о., разработка архитектуры неразрывно связана с
декомпозицией (с разбиением) создаваемой системы на
части и определением основных принципов проекта
Слайд 5
Архитектура ПО
Разработка архитектуры является первым этапом борьбы со
сложностью ПО, на котором реализуется принцип выделения относительно независимых
компонент
Основные задачи разработки архитектуры ПС:
выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;
определение способов взаимодействия между выделенными программными подсистемами.
Различают следующие основные классы архитектур программных средств:
цельная программа;
комплекс автономно выполняемых программ;
слоистая программная система;
коллектив параллельно выполняемых программ.
Слайд 6
Архитектура ПО
Цельная программа представляет вырожденный случай архитектуры ПС:
в состав ПС входит только одна программа. Такую архитектуру
выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и ее реализация не представляется слишком сложной.
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
любая из этих программ может быть активизирована (запущена) пользователем;
при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;
все программы этого набора применятся к одной и той же информационной среде.
Таким образом, программы этого набора по управлению никак не взаимодействуют - взаимодействие между ними осуществляется только через общую информационную среду.
Слайд 7
Архитектура ПО
Слоистая программная система состоит из некоторой
упорядоченной
совокупности программных подсистем, называемых
слоями, такой, что:
на каждом
слое ничего не известно о свойствах (и даже
существовании) более высоких слоев;
каждый слой может взаимодействовать по управлению
(обращаться к компонентам) с непосредственно соседствующим
более низким слоем через заранее определенный интерфейс,
ничего не зная о его внутреннем строении;
каждый слой располагает определенными ресурсами, которые он
либо скрывает от других слоев, либо предоставляет непосредственно
более высокому слою (через указанный интерфейс) некоторые их
абстракции.
Связи между слоями ограничены передачей значений параметров
обращения каждого слоя к смежному снизу слою и выдачей
результатов этого обращения от нижнего слоя верхнему.
Нельзя использовать глобальные данные несколькими слоями
Слайд 8
Архитектура ПО
Пример слоистой архитектуры операционной системы THE:
Коллектив параллельно
действующих программ представляет собой набор программ, способных взаимодействовать между
собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько центральных процессоров, а во-вторых, выполнять между собой динамические (в процессе выполнения) обмены сообщениями, на базе которых производиться их синхронизация.
Слайд 9
Архитектура ПО
В более общем случае коллектив параллельно действующих
программ может быть организован в систему с портами
сообщений.
Порт сообщений представляет собой программную подсистему,
обслуживающую некоторую очередь сообщений: она может
принимать на хранение от программы какое-либо сообщение,
ставя его в очередь, и может выдавать очередное сообщение
другой программе по ее требованию. Сообщение, переданное
какой-либо программой некоторому порту, уже не будет
принадлежать этой программе (и использовать ее ресурсы),
но оно не будет принадлежать и никакой другой программе,
пока в порядке очереди не будет передано какой-либо программе
по ее запросу. Таким образом, программа, передающая
сообщение не будет находиться в стадии ожидания пока
программа, принимающая это сообщение, не будет готова
его обрабатывать (если только не будет переполнен
принимающий порт).
Слайд 10
Два способа декомпозиции сложных систем:
а)создание проекций системы,
б) разбиение на отдельные части
Слайд 11
Пример системы безопасности жилого дома
Квартиросъемщик
Собственник дома
Слайд 12
Архитектура ПО: примеры проекций
Слайд 17
Архитектура ПО: Множественность точек зрения
При разработке архитектуры ПО
важным оказывается совмещение множества точек зрения. ПО оказывается настолько
сложным, что его архитектуру не построить как единую модель – множество отдельных аспектов должны быть представлены в архитектуре, их связи сложны и плохо выразимы в явном виде. Полезнее оказывается создание множества моделей, созданных с разных точек зрения.
Разработчик
Слайд 18
Множественность точек зрения происходит также от того, что
нет единых стандартов и норм разработки ПО. То есть
разработка ПО во многом «state of art».
Точка зрения (viewpoint) — это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта. Точку зрения нужно ясно осознавать при создании визуальных моделей, например, модели случаев использования. Важно понимать, что она может быть в каждом конкретном случае своя. Важнейшими характеристиками точки зрения моделирования является цель (зачем создается модель) и целевая аудитория (то есть, для кого она предназначается).
Архитектура ПО: Множественность точек зрения
Слайд 19
Архитектура ПО: Документирование
Часто понятие архитектуры сильно сужают, понимая
под ним лишь описание основных, важных аспектов ПО, создаваемых,
например, архитектором при разработке дизайна системы. Для этих целей используется язык моделирования UML (Unified
Modeling Language).
Слайд 20
Архитектура ПО: Документирование