Л а б о р а т о р н а я р а б о т а № 3

«Построение модели архитектуры на примере реализации стратегической игры»

Цель работы: освоить комплексное применение паттернов проектирования при проектировании архитектуры программного обеспечения

Продолжительность работы - 8 часов.

Содержание

1. Теоретический материал..........................................................................................................1 2. Задание на выполнение лабораторной работы.......................................................................4 3. Требования к отчету................................................................................................................4

Архитектура «4+1»

Один из способов описания архитектуры носит название Архитектура «4+1».

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

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

При использовании подхода «4+1» разработчики ПО начинают формирование архитектуры с типичного набора видов, представленного на рисунке.

Набор видов включает:

1. Use case вид, который содержит прецеденты и сценарии, охватывающие архитектурно существенное поведение, классы или технические риски. Вид является подмножеством модели прецедентов.

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

3. Вид с позиции разработки, который содержит краткий обзор модели выполнения в терминах модулей пакетов и уровней. Здесь описывается также распределение пакетов и классов (из логического представления) в пакетах и модулях представления выполнения. Это представление является подмножеством модели выполнения.

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

5. Физический вид, который содержит описание различных физических узлов для наиболее типичных конфигураций платформы, и расположение задач (из представления процесса) по физическим узлам. Потребность этого представления возникает, только если система распределена.

Дополнительные представления, например для представления интерфейса пользователя, представления защиты и представление данных не отвергаются, но ответственность за их связывание с базой «4+1» ложится непосредственно на программистов.

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

Структура модели - организационные элементы, например, иерархическое представление.

Существенные элементы - критические прецеденты, главные классы, общие механизмы и так далее, а не все элементы, представленные в модели.

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

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

Одним из принципиальных подходов к архитектурным представлениям ПО является ориентация на паттерны проектирования, что в архитектурах ПО привело к направлению «Patten-Oriented Software Architecture», то есть к архитектурам, ориентированным на паттерны. Следует отметить, что ориентация на паттерны используется в любых версиях построения архитектур.

Сущность этого направления заключается в следующем понимании паттерна:

«паттерн проектирования – это способ представления в общем виде как условия проектной задачи, так и правильных подходов к еѐ решению»

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

Имя_ паттерна (Контекст, Задача (Проблема), Решение, Результаты).

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

Для управляемого применения паттерна необходимо сформулировать Задачу и еѐ Контекст. Также может быть включен перечень условий, при выполнении которых стоит применять паттерн.

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

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

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

В нашей работе мы будем исходить из рассмотренных ранее паттернов проектирования GoF.

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

4. Задание

1. Разработать пошаговую военную стратегию для игры в рамках экрана монитора игрока и компьютера.

Для этого построить модель архитектуры «4+1» и написать код программы на языке программирования С++ или С# или Java.

5. Требования к отчету

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

4