Шаблон «Многоуровневая (многослойная) архитектура»
Многоуровневая архитектура обеспечивает группировку связанной функциональности приложения в разных слоях, выстраиваемых вертикально, поверх друг друга. Функциональность каждого слоя объединена общей ролью или ответственностью. Слои слабо связаны, и между ними осуществляется явный обмен данными.
(слой обозначает логическое разделение функциональности, а уровень физическое разворачивание на разных системах).
При строгом разделении на слои компоненты одного слоя могут взаимодействовать только с компонентами того же слоя или компонентами слоя, расположенного прямо под данным слоем. Более свободное разделение на слои позволяет компонентам слои взаимодействовать с компонентами того же и всех нижележащих слоев.
Многослойная архитектура поддерживается рядом шаблонов проектирования. Например, под названием Отделение представления объединяется ряд шаблонов, разделяющих взаимодействие пользователя с UI, представление, бизнес-логику и данные приложения, с которыми работает пользователь.
Структура
Применимость
- имеются готовые уровни, подходящие для повторного использования в других приложения;
- имеются приложения, предоставляющие подходящие бизнес-процессы через интерфейсы сервисов;
- создается сложное приложение и предварительное проектирование требует разделения, чтобы группы могли сосредоточиться на разных участках функциональности;
|
|
|
- приложение должно поддерживать разные типы клиентов и разные устройства;
- требуется реализовать сложные и/или настраиваемые бизнес-правила и процессы.
Унифицированный процесс разработки ПО (RUP)
Основные черты. Фазы и основные потоки работ.
RUP (рациональный унифицированный процесс) – совокупность рекомендаций к выполнению различной деятельности, необходимых для преобразований требований к системе в ПО.
Основные черты RUP:
1.использование UML (унифицированный язык моделирования).
2.Компонентно-ориентированная технология.
3.Процесс разработки программ управляется прецедентами.
Прецедент – часть функциональности системы, необходим для получения пользователем полезного и приятного результата.
Прецедент – это последовательность действий актанта и реакция системы, приводящая к полезному для актанта результату (последовательность действий пользователя и реакции системы).
Актанты – внесистемные агенты, которые взаимодействуют с системой.
Созданием прецедента мы задаем функциональные требования к системе.
Требования -> Анализ-> Проектирование-> Реализация. Прецедент используется для написания тестов. По прецедентам создаются тесты. Формируется модель прецедента. Они являются основой для разработки системы. В процессе тестирования сравниваются результаты действия системы и результаты тестов.
|
|
|
Унифицированный процесс ориентирован на архитектуру.
Архитектура – набор решений по организации программной системы (выбор элементов структуры ПС, их интерфейсов и правил взаимодействий).
Примеры
а) Брокер (механизм управления интерфейсов и правил взаимодействия).
б) Слои (абстрактные машины) – приложение разбивается на уровни. Каждый уровень имеет сведения об организации следующего нижнего уровня.
в) Клиент-сервер – клиентская часть взаимодействует с пользователем, а все действия выполняются на сервере.
4.процесс является интерактивным и инкрементным. Сначала создается скелет, а потом добавляются элементы
Цели выполнения на конец фаз разработки:
- Начало: Определение целей и задач разработки. Понимание проблем заинтересованных лиц.
- Развитие: Определение требований к системе, разработка базовой архитектуры системы. Определение стоимости разработки, составление плана разработки.
- Конструирование: Создание программного продукта.
- Переход: Доводка системы. Внедрение системы в эксплуатацию.
|
|
|
Виды работ (разработка ПО)
- Бизнес-моделирование
- Оформление требований к системе – описание того, что система должна делать
- Анализ требований и проектирование – создание статических и динамических моделей системы, выполняющей выявленные требования
- Реализация – производство программного кода, который превращается в исполняемую систему.
- Тестирование – проверки системы в целом.
- Размещение
Процесс разработки представляется как серия итераций. На каждой итерации выполняются все виды работ, поэтому каждая итерация заканчивается версией системы. В отдельной итерации реализуется некоторое подмножество функциональных требований. Система эволюционирует – количество реализованных требований увеличивается с каждой итерацией.
Роль требований в жизненном цикле разработки программного обеспечения:
Модель вариантов использования разрабатывается посредством нескольких приращений. Каждая итерация добавляет к модели новые варианты использования и добавляет новые подробности к описанию уже существующих.
Дата добавления: 2018-06-01; просмотров: 322; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!