МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение

высшего образования
«МИРЭА – Российский технологический университет»
РТУ МИРЭА
Институт информационных технологий

Кафедра корпоративных информационных систем

Практическая работа №2
по дисциплине
« Архитектура, проектирование и разработка программных средств »

Студент группы ИКМО-03-21: Канте М. М.

(подпись и расшифровка подписи)

Преподаватель
Чехарин Е. Е.
(подпись и расшифровка подписи)
Москва 2022
 Оглавление

Оглавление 1
Список аббревиатур и сокращений 3
Введение 4
Часть 1: Обзор методологии 6
1. Требования и ограничения 6
1.1. Цель проектирования 6
1.2. Атрибуты качества, нефункциональные требования 6
1.3. Функциональные требования 6
1.4. Системные требования 7
1.5. Ограничения 7
2. Собираем требования 8
3. Проектируем архитектуру 9
3.1. Шаг 1: Проверка входных данных 10
3.2. Шаг 2: Определяем список требований к подсистеме 10
3.3. Шаг 3: Выбираем часть системы для проектирования 11
3.4. Шаг 4: Определяем лучший вариант из возможных 11
3.5. Шаг 5: Конкретизируем компоненты выбранной концепции,
определяем обязанности и интерфейсы 11
3.6. Шаг 6. Делаем эскиз решения и краткое описание 11
3.7. Шаг 7. Проверка выполнения требований 11
4. Отслеживаем прогресс 13
Часть 2: внедрение методологии ADD 14
1. Варианты использования 14
2. Атрибуты качества 16
3. Ограничения 17
4. Архитектурные задачи 17
5. Процесс проектирования 17
5.1. Шаг 1: Проверка и анализ исходных данных 17
5.2. Шаг 2: Определяем список требований к подсистеме 18
5.3. Шаг 3: Выбор элемента системы для проработки 19

1
 5.4. Шаг 4: Выбор архитектурных концепций 19
5.5. Шаг 5: Конкретизируем компоненты выбранной концепции,
определяем обязанности и интерфейсы 20
5.6. Шаг 6: Определите интерфейсы для инстанцированных
элементов 20
5.7. Шаг 7: Анализ созданной архитектуры и прогресса 21
Заключение 22
Источник 23
Список рисунков и таблиц 24

2
 Список аббревиатур и сокращений

- ПО – программное обеспечение
- ТЗ – техническое задание
- ABD – Architecture Based Design
- ADD – Attribute Driven Design
- HH – High High
- HL – High Low
- HM – High Medium
- HML – High Medium Low
- HTTP – Hypertext Transfer Protocol
- IT – Information technology
- LH – Low Medium
- LL – Low Low
- LM – Low Medium
- MH – Medium High
- ML – Medium Low
- MM – Medium Medium
- MVC – Model View Controller

3
 Введение

Архитектура приложения – это его технологическая база, которая

учитывает риски проекта, бюджет, требования и ограничения, потребности
в масштабировании.
Помимо разработки архитектуры, на старте требуется
приблизительно оценить объем и стоимость проекта. Для этого мы в своей
практике используем одну из проверенных методологий создания
архитектуры ПО – Attribute-Driven Design (ADD). При этом мы опираемся
на атрибуты качества того или иного IT-продукта. На их основе мы на
этапе оценки (пресейла) создаём архитектурную концепцию системы.
Проектирование на основе атрибутов (также называемое ADD или
метод проектирования на основе атрибутов) - это методология создания
архитектуры программного обеспечения, учитывающая атрибуты качества
программного обеспечения. Ранее она была известна как метод
проектирования на основе архитектуры (или ABD), но из-за проблем с
торговой маркой название было изменено на проектирование на основе
атрибутов примерно в 2001 году.
Именно IT-архитектор решает, как в конечном итоге будет выглядеть
информационная система — в целом и в деталях. Ему требуется найти
баланс между конкурирующими требованиями и ограничениями.
Если у вас есть детальное архитектурное решение, это позволит
наиболее точно оценить сроки и стоимость реализации продукта. Кроме
того, появляется возможность уже на старте определить характеристики
системы, которая будет соответствовать бизнес-задачам. Среди критериев
качества архитектуры – гибкость для масштабирования, снижение рисков,
скорость работы и возможность независимого выбора подрядчиков.
Рассмотрим этапы работы с архитектурной концепцией, возможные

4
сложности и решения, исходя из опыта нашего Архитектурного комитета.
Мы надеемся, что статья будет полезна архитекторам и разработчикам,
желающим освоить методологию ADD, и может быть интересна смежным
специалистам.

5
 Часть 1: Обзор методологии

1. Требования и ограничения
Наша цель — спроектировать архитектуру систематическим,
предсказуемым и экономически эффективным способом. Для этого нужно
определить требования к продукту. И в нашем случае проект, который мы
будем делать, - это ежедневник.
Как правило, техническое задание (ТЗ) на разработку продукта
содержит требования, но не всегда они указаны в достаточном объеме. По
этой причине в числе ключевых задач IT-архитектора – сбор и анализ
требований, создание дизайна архитектуры и описание решения, его
проверка, а также контроль и надзор во время разработки ПО.
Рассмотрим, что входит в список требований:
1.1. Цель проектирования
От цели зависит, что нам нужно на старте: детальная архитектура
или приблизительное представление об устройстве системы, которое
позволит оценить объем и стоимость работ.
Целью данного проекта является разработка информационной
системы для ежедневника. Информационная система ежедневника должна
быть простой, интуитивно понятной и эргономичной для использования
любым пользователем.
1.2. Атрибуты качества, нефункциональные требования
Эти атрибуты определяют свойства системы, которые она должна
демонстрировать – требования к производительности, доступности,
безопасности, удобству использования. Пример: система должна работать
24х7, допускается простой не более 30 минут в месяц.
1.3. Функциональные требования
Определяют действия, которые система способна выполнить.

6
Пример: возможность выгружать данные из файла и рассылать отчеты по
email.
1.4. Системные требования
Возникают постепенно в процессе детализации и реализуются
итеративно. Пример: авторизация, ведение журнала действий,
кэширование.
1.5. Ограничения
Не относятся напрямую к поведению системы и не поддаются
нашему влиянию. Например, у клиента есть пожелания по разработке
микро сервисной, а не монолитной архитектуры. Также сюда относятся
требования законодательства, например, в области хранения персональных
данных.
Как правило, владелец продукта заранее не имеет полного списка
требований к системе, поэтому архитектор непосредственно организует
процесс их сбора и фиксации. Из всех требований к системе специалист
обязан выделить архитектурно значимые, которые оказывают глубокое
влияние на конечное решение.
Согласно методологии ADD, сбор требований – это первый этап работы.
Его назначение:
- помочь оценить стоимость и график работ;
- выработать ключевые технологии;
- обеспечить достижение бизнес-целей в процессе разработки.
Далее рассмотрим остальные этапы проектирования.

7
 2. Собираем требования

В качестве источника могут выступать результаты опросов

стейк-холдеров, анализ бизнес-целей проекта и историй использования
(user story). При этом важно конкретизировать, что имеет в виду клиент.
Например, не просто «безотказная работа сайта», а «допустимый период
простоя – 30 минут в месяц».
Далее мы оцениваем важность требований по двум критериям:
- ценность для бизнеса;
- степень влияния на архитектуру.
Уровни важности оцениваем по шкале HML (high, medium, low —
высокий, средний, низкий). Таким образом, каждое требование будет
иметь двухбуквенное сочетание. Архитектурно значимые пункты имеют
обозначения HH, HM, HL, MH, MM. Стоит отметить, что большое число
требований HH означает высокие риски на проекте.

8
 3. Проектируем архитектуру
Мы проектируем архитектуру ПО, исходя из наиболее значимых
атрибутов качества. Это рекурсивный процесс, в ходе которого система
декомпозируется на более мелкие подсистемы.
ADD — первый метод, который концентрируется на атрибутах
качества и способах их достижения. Важным вкладом ADD было
признание того, что анализ и документация являются неотъемлемой
частью процесса проектирования. Этот метод успешно применяется более
15 лет.
Сейчас актуальная версия ADD — 3.0, итеративная. Согласно ей,
проектирование выполняется поэтапно в течение всего времени
разработки системы, в каждом спринте. В ней по шагам описано
руководство по тем задачам, которые необходимо выполнить в рамках
каждой итерации.

9
 Рисунок 1 – Attribute Driven Design
(https://habr.com/ru/company/simbirsoft/blog/571554/)

3.1. Шаг 1: Проверка входных данных

Убеждаемся, что все необходимые данные и требования доступны,
приоритезированы, корректны и выполнимы, а цель работы понятна.
3.2. Шаг 2: Определяем список требований к подсистеме
Ранжируем требования по важности для бизнеса и степени влияния
на архитектуру, группируем в соответствии с оценкой HML, выбираем 5-6
приоритетных. Устанавливаем цель каждой итерации.

10
 3.3. Шаг 3: Выбираем часть системы для проектирования
Исходим из риска и сложности реализации, ценности для бизнеса,
критического пути и точности проработки требований. Строим работу на
достижении требований, которые соответствуют целей итерации.
3.4. Шаг 4: Определяем лучший вариант из возможных
Самый сложный пункт. Анализируем все варианты, находим
преимущества и недостатки.
3.5. Шаг 5: Конкретизируем компоненты выбранной
концепции, определяем обязанности и интерфейсы
Как правило, в начале работы концепция формулируется в общем
виде. На данном этапе мы определяем все элементы подсистемы и
ответственность каждого, выбираем интерфейс, через который
компоненты взаимодействуют между собой.
3.6. Шаг 6. Делаем эскиз решения и краткое описание
Оформляем описание в наглядный документ, например, в виде
UML-диаграммы. Нужно также зафиксировать все принятые решения,
описать, на какие компромиссы мы пошли и какие альтернативы
рассмотрели. Это поможет в дальнейшем оценить аргументы в пользу
конкретной архитектуры и создать документацию.
3.7. Шаг 7. Проверка выполнения требований
На этом шаге методология рекомендует получить “второе мнение”
других опытных коллег-архитекторов, для того чтобы подойти к процессу
более объективно. Участие нескольких специалистов с их опытом и точкой
зрения на архитектуру поможет оперативно выявить недочеты, если они
есть.

Важно: Мы уточняем и конкретизируем требования, расставляем

приоритеты и затем повторяем шаги со 2 по 7 в каждой итерации. Таким
образом необходимо проработать все требования с высоким приоритетом,

11
соблюдая все ограничения. Но не обязательно проводить итерации
последовательно. Скорее всего, вы будете чередовать этапы
проектирования и реализации системы.

12
 4. Отслеживаем прогресс

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

нужно наблюдать за прогрессом работы команды и оперативно
откликаться на изменения. Авторы методологии советуют отслеживать
выполнение шагов с помощью архитектурного бэклога в виде
канбан-доски. В ее столбцы мы помещаем архитектурно значимые
требования, ограничения и системные задачи.
Они могут иметь следующие статусы:
● Not Yet Addressed (Еще не рассмотрено)
● Partially Addressed (Рассмотрено частично)
● Completely Addressed (Рассмотрено полностью)
● Discarded (Отброшено)

13
Часть 2: внедрение методологии ADD

В этом разделе мы будем использовать методологию ADD для

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

1. Варианты использования

ID Вариант использования Описание

UC-1 Посмотреть список задач
UC-2 Забрать и отправить список задач
UC-3 Создать новую задачу
При доступе пользователя к
приложению платформа
сделает HTTP-запрос к серверу,
который вернет список задач в
формате JSON.
При доступе пользователя к
приложению платформа
сделает HTTP-запрос к серверу,
который вернет список задач в
формате JSON.
Пользователь вводит данные
задачи, которые после проверки
будут отправлены на сервер с

14
 помощью метода HTTP,
который будет обрабатывать
регистрацию
UC-4 Создайте новую категорию Пользователь вводит данные
задачи, которые после проверки
будут отправлены на сервер с
помощью метода HTTP,
который будет обрабатывать
регистрацию
UC-5 Отметить задание как выполненное Чтобы отметить задачу как
завершенную, пользователь
должен нажать
соответствующую кнопку,
после чего идентификатор
соответствующей задачи будет
отправлен на сервер с помощью
HTTP-метода, что изменит
статус задачи
UC-6 Удалить задачу Чтобы удалить задачу,
пользователь должен будет
нажать соответствующую
кнопку, при этом ID
соответствующей задачи будет
отправлен на сервер через
HTTP-метод, который изменит
статус задачи.
UC-7 Удалить категорию Чтобы удалить категорию,
пользователь должен будет
нажать соответствующую
кнопку, при этом
идентификатор
соответствующей задачи будет
отправлен на сервер через
HTTP-метод, который изменит
состояние задачи

Таблица 1 – Варианты использования

15
 Рисунок 2 – Диаграмма вариантов использования

2. Атрибуты качества

ID Атрибут Описание
QA-1 Быстродействие Минимизировать вес приложения и тем
самым увеличить производительность и
разместить большее количество
пользователей.
QA-2 Масштабируемость Система должна быть способна справиться
с возросшей нагрузкой. Она неравномерна:
от 0 до 1000 запросов в секунду.
QA-3 Экономичность Необходимо оптимально использовать
вычислительные ресурсы, чтобы

16
 минимизировать плату за их аренду.
QA-4 Эргономичный Система должна быть простой в
использовании, чтобы привлечь большое
количество пользователей.
Таблица 2 – Атрибуты качества

3. Ограничения

ID Описание
CON-1 Система должна быть развернута в облаке AWS.
CON-2 Данные пользователей будут храниться на Firebase.
CON-3 Код серверного приложения будет написан на PHP, а
клиентская часть будет написана на Vue.js
Таблица 3 – Ограничения

4. Архитектурные задачи

ID Описание
CRN-1 Спроектировать и описать высокоуровневую архитектуру
системы
Таблица 4 – Архитектурные задачи

5. Процесс проектирования

После фиксации требований мы подготовились к тому, чтобы начать

первую итерацию ADD.
5.1. Шаг 1: Проверка и анализ исходных данных
Цель проектирования: Спроектировать систему с нуля. Работа
должна быть выполнена в виде последовательных коротких итераций,
чтобы оперативно получать обратную связь.

17
 Основные функциональные требования указаны в таблице 1.
Давайте повторим здесь атрибуты качества и добавим требования к
приложению:

ID Важность Сложность
QA-1 Высокая Средняя
QA-2 Высокая Средняя
QA-3 Высокая Высокая
QA-4 Средняя Средняя
Таблица 5 – Атрибуты качества + уровень качества

Поскольку проект дневника не является большим проектом, а скорее

частью приложения, мы будем использовать дневник как единый
компонент.
5.2. Шаг 2: Определяем список требований к подсистеме
Список требований к компоненту следующий :
- Диаграмма вариантов использования показана в таблице 1;
- Атрибуты качества в таблице 2;
- ограничения приведены в таблице 3;
- Архитектурные задачи:

Рисунок 3 – Архитектура компонента ежедневника

18
 5.3. Шаг 3: Выбор элемента системы для проработки
Прорабатываем структуру всей системы.
5.4. Шаг 4: Выбор архитектурных концепций
Архитектурой для реализации проекта и компонента является
архитектура MVC.
Model-View-Controller (MVC, «Модель-Представление-Контроллер»,
«Модель-Вид-Контроллер») – схема разделения данных приложения и
управляющей логики на три отдельных компонента: модель,
представление и контроллер – таким образом, что модификация каждого
компонента может осуществляться независимо.
Модель (Model) предоставляет данные и реагирует на команды
контроллера, изменяя свое состояние.
Представление (View) отвечает за отображение данных модели
пользователю, реагируя на изменения модели.
Контроллер (Controller) интерпретирует действия пользователя,
оповещая модель о необходимости изменений.

Рисунок 4 – Схема архитектуры Model View Controller

19
 5.5. Шаг 5: Конкретизируем компоненты выбранной
концепции, определяем обязанности и интерфейсы

Решение Обоснование
Для клиентской части - Все вычисления на уровне интерфейса
мы будем использовать будут выполняться на стороне клиента
Vue.js (QA-1, QA-2, QA-3)
- Фреймворк Vue.js очень отзывчив и в
сочетании с хорошим дизайном будет
очень эргономичным (QA-1)
Серверная часть будет - К серверу будут обращаться только для
реализована в виде запросов (QA-1, QA-2, QA-3)
REST API
На стороне клиента - Это значительно сократит количество
будет реализована запросов клиентов к серверу (QA-1,
система кэширования QA-2, QA-3)
Таблица 6 – Конкретизируем компоненты выбранной концепции, определяем
обязанности и интерфейсы
5.6. Шаг 6: Определите интерфейсы для инстанцированных
элементов

Рисунок 5 – интерфейсы для инстанцированных элементов

20
 5.7. Шаг 7: Анализ созданной архитектуры и прогресса
Цель итерации достигнута. Общая структура системы
спроектирована. В качестве основы мы выбрали проверенный временем
архитектурный стиль, подходящий под условия нашей задачи.

21
 Заключение

Целью данной практической работы было представить методологию

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

22
 Источник

- https://habr.com/ru/company/simbirsoft/blog/571554/
- https://en.wikipedia.org/wiki/Attribute-driven_design
- https://online-edu.mirea.ru/mod/resource/view.php?id=134906
- https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8319
- https://www.philadelphia.edu.jo/academics/lalqoran/uploads/SAADD.pdf
- https://jijoy.medium.com/attribute-driven-design-119d8467c6b5
- https://ru.wikipedia.org/wiki/Model-View-Controller

23
 Список рисунков и таблиц

- Рисунок 1 – Attribute Driven Design (страница 10)

- Рисунок 2 – Диаграмма вариантов использования (страница 16)
- Рисунок 3 – Архитектура компонента ежедневника (страница 18)
- Рисунок 4 – Схема архитектуры Model View Controller (страница 19)
- Рисунок 5 – интерфейсы для инстанцированных элементов
(страница 20)
- Таблица 1 – Варианты использования (страница 15)
- Таблица 2 – Атрибуты качества (страница 17)
- Таблица 3 – Ограничения (страница 17)
- Таблица 4 – Архитектурные задачи (страница 17)
- Таблица 5 – Атрибуты качества + уровень качества (страница 18)
- Таблица 6 – Конкретизируем компоненты выбранной концепции,
определяем обязанности и интерфейсы (страница 20)

24