ОПОРНЫЕ ТОЧКИ ЗРЕНИЯ

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

Поскольку таких точек зрения слишком много, из них выбираются «опорные» точки зрения.

Точка зрения может интерпретироваться следующим образом:

1) Как источника информации о системных данных.

2) Как структура представлений.

3) Как получатель системных сервисов.

На основе понятия точки зрения был создан метод VORD (Viewpoint Oriented Requirements Definition — определение требований на основе точек зрения), здесь точка зрения понимается как получатель системных сервисов.

Этапы:

1) Идентификация точек зрения и связанных с ними сервисов;

2) Структурирование точек зрения — строится иерархия точек зрения, общесистемные сервисы связываются с верхними уровнями иерархии и наследуются точками зрения, расположенными по иерархии ниже;

3) Документирование точек зрения;

4) Отображение точек зрения на системные объекты.

АРХИТЕКТУРНОЕ ПРОЕКТИРОВАНИЕ

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

Входные данные для архитектурного проектирования — это системные требования.

Архитектурное проектирование включает в себя три этапа:

1) Структурирование системы — выделяются основные системы и определяется порядок их взаимодействия;

2) Моделирование управления — разрабатывается базовая модель взаимодействия подсистем и компонентов;

3) Модульная декомпозиция — разбиение подсистем на модули.

На выходе получаем детальный проект системы.

Чёткой границы между этапа нет, работаем до тех пор, пока не будет создан проект системы.

Подсистема от модуля отличается:

· масштабом;

· подсистемы — это независимые части системы;

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

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

Четыре типа архитектурных моделей, разрабатываемых в ходе архитектурного проектирования:

1) Статическая структурная модель — на ней представлены подсистема и компонента.

2) Динамическая модель процессов — на ней показывается, какие процессы протекают во время работы системы (например, диаграмма видов деятельности).

3) Интерфейсная модель — описывает сервисы, предоставляемые каждой подсистемой посредством общего интерфейса системы.

4) Модели отношений — показывает отношения между компонентами системы (передачи сообщений, данных и так далее, например — диаграмма последовательностей).

Для описания этих моделей используются языки описания архитектуры. Язык UML — унифицированный язык описания архитектуры.

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

Этот выбор влияет на ряд характеристик будущего программного продукта:

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

2) Защищённость — если это наиболее критический показатель, то целесообразно реализовать программный продукт в виде многоуровневой архитектуры.

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

4) Надёжность (чтобы реже «падало») — если это наиболее критический показатель, то применяем архитектуру, включающую избыточные компоненты; то есть, чтобы моно было заменять компоненты, не останавливая работу системы.

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

Эти требования противоречивы.

1) Структурирование системы

Предполагает представление системы в виде взаимодействующих подсистем.

Примеры архитектуры систем:

1. Модель репозитория. Такая архитектура системы, в котором хранение данных реализовано централизованно.

Альтернатива — у каждой подсистемы данные хранятся отдельно.

Централизованное хранилище данных предполагает, что одна и та же модель данных (структура БД) используется для всех подсистем.

Плюсы: избегаем необходимости передавать большие объемы данных от одной подсистемы к другой.

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

Минус2: Могут возникнуть проблемы с добавлением новой подсистемы, так как её структура данных может быть не адаптируемой.

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

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

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

Плюс: модель репозитория прозрачна с точи зрения добавления новых подсистем. Новая подсистема просто должна быть совместима с системой по методу хранения данных.

2) Модель «клиент-сервер».

Эта модель распределенной системы, которая включает в себя три основных компонента:

— набор автономных серверов (программных компонентов), предоставляющих сервисы другим подсистем.

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

— сеть, связывающую клиентов с сервисами.

Плюс: в систему легко добавлять новых клиентов

Плюс: в систему легко добавлять новый север

Плюс: всё хорошо с надёжностью, так как выход из строя первого сервера не влияет на другие.

Минус: если перегрузка сети и выход из строя каналов, то отдельные сервисы являются недоступными, то есть надёжности каналов связи — узкое место.

Дальнейшее развитие: это сервис-ориентированные архитектуры (SOA). Идея: помнить, что программный продукт разрабатывается для обслуживания бизнес-процессов и разрабатывать архитектуру для этого (компонентов бизнес-процессов).

3) Модель абстрактной машины (модель многоуровневой архитектуры)

Жирный прямоугольник — интерфейс. Реализуется компонент 1, пишется его интерфейс, по нему пишется компонент 2, его интерфейс и так далее, пока не будет реализован интерфейс системы.

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

Модель называется «моделью абстрактной машины», так как каждый компонент реализует абстрактную машину и предоставляет свой машинный язык.

Основное преимущество модели абстрактной машины:

+ переносимость программного продукта

+ защищенность программного продукта (сбой на внешних компонентах не влияет на базовые функции)?????????????????????

Минусы:

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

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

Поиск по сайту: