Оценка архитектуры программного обеспечения с помощью TARA

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Что такое оценка архитектуры программного обеспечения?

Гораздо лучше обнаружить недостающую спальню, пока архитектура является только чертежом, а не в день переезда. (Paul Clements)

При оценке архитектуры программного обеспечения вы пытаетесь найти проблемы в архитектуре / имплементации. Когда вы можете это сделать?

  • Поиск ошибок на ранней стадии во время проектирования

  • Во время разработки, чтобы сравнить реализацию с проектом

  • В процессе технического обслуживания и дальнейшего развития.

На практике оценка чаще всего проводится после того, как имплементация завершена и проект уже находится в производстве.

Что такое TARA?

Метод небольшого архитектурного обзора (TARA) был изобретен для ситуаций, когда исчерпывающий метод неприменим. TARA не основан на сценариях, как методы типа ATAM, а опирается на промышленный опыт. Он гибкий и простой в использовании. TARA сэкономит ваше время и ресурсы.

Когда использовать TARA?

  • Нет времени и нет возможности использовать сценарный подход.

  • Система уже внедрена

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

  • Предназначен для одного аудитора без участия многих заинтересованных сторон

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

7 шагов TARA

1. Контекстная диаграмма и требования

Сначала мы должны выяснить, в каком контексте живет система и какие требования качества должны быть удовлетворены. Нам также необходимо узнать какие ключевые функции доступны. Вы можете определить контекст и наиболее важные функциональные требования, расспросив членов команды и пользователей системы. Сложнее выявить требования к качеству, потому что в большинстве случаев команде не удается их четко сформулировать. Рекомендуется предлагать некоторые требования к качеству (нефункциональные требования), такие как производительность или масштабируемость, исходя из контекста приложения/системы.

2. Функциональные представления и представления развертывания

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

3. Анализ кода

Базовый анализ кода охватывает следующую информацию для оценки:

  • Структура модуля и зависимости

  • Измерения, такие как строки кода (LOC), количество классов, тестовых классов или размер двоичных файлов

  • Результаты статического анализа кода, такие как цикломатическая сложность, дублирование кода, соотношение комментариев к коду и стиль кода

  • Покрытие тестов

4. Оценка требований

Теперь нам необходимо выяснить, насколько хорошо система соответствует функциональным и качественным требованиям. Эксперт должен оценить, как успешно, выполнены требования, по шкале от 1 до 5 или с помощью флажков -  высокий / средний / низкий. В конце должен быть четкий список требований и уровень их выполнения.

5. Определение и отчет о результатах

Когда вы закончите шаг 4, то обнаружите положительные и отрицательные аспекты системы. Все должно быть сообщено конфиденциальным образом, а результаты должны быть сгруппированы с заголовком и помечены идентификатором.

6. Подготовьте выводы для спонсора

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

7. Предоставление выводов и рекомендаций

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

Пример веб-приложения

Давайте попробуем оценить веб-приложение и посмотрим, как работают эти шаги:

Контекстная диаграмма
Контекстная диаграмма

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

Эскиз функционального представления
Эскиз функционального представления

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

  • ФТ1 (функциональное требование)  - Обслуживание данных: Пользователь должен иметь полную поддержку CRUD с возможностью выбора нескольких действий.

  • ФТ2 - Обогащение данных: Добавленные данные автоматически обогащаются  из внешнего API.

  • НФТ1 (нефункциональное требование) - Доступность: Веб-приложение должно быть доступно 99,99% времени.

  • НФТ2 - Производительность пользовательского интерфейса: Пользовательский интерфейс никогда не должен зависать и реагировать на основные действия менее чем за 1 секунду. Для длительных действий должен отображаться индикатор выполнения.

Следующим шагом является анализ кодовой базы, вот что мы обнаружили:

  • Размер имплементации: 200 классов Java, 34 таблицы базы данных и 327586 строк кода

  • Размер теста: 40 тест-кейсов, ссылающихся на 85 классов

  • Структура: Одна базовая структура приложения Spring с 10 модулями

  • Запутанный код: 1 базовый пакет Java "com.mysystem.app".

  • Стандарт кодирования: Используется стандарт кодирования Google Java Style.

Теперь мы расскажем о том, что мы нашли в приложении, и оценим это в соответствии с требованиями, изложенными выше:

  • Вывод 1 - Функциональность CRUD, включая пакетную обработку, предоставлена и работает так, как ожидалось. 5/5

  • Вывод 2 - Обогащение данных выполняется специальным компонентом и может быть назначено модулем cron runner. Пользователи ожидали, что у них будет UI (пользовательский интерфейс) для изменения запланированных автоматических заданий обогащения, но возможны только корректировки на основе файлов. 4/5

  • Вывод 3 - Приложение развернуто на двух серверах с балансировщиком нагрузки, управляющим трафиком. Различные серверы приложения находятся в одном центре обработки данных, из-за этого в случае выпадения данных такая ситуация приводит к полному простою.  4/5

  • Вывод 4 - После измерения среднего арифметического времени отклика UI, он срабатывает в течение 100 мс с момента запуска локальных событий действия. 5/5

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

  • Рекомендация 1 - API не использует никакой системы кэширования. Для повышения производительности при работе с несколькими клиентами, промежуточная система кэширования или обратный кэширующий прокси просто необходимы.

  • Рекомендация 2 - Необходимо имплементировать UI для настройки времени автоматического обогащения данных. Изменение файлов, которое может быть выполнено только IT-экспертом, а не администратором, блокирует рабочий процесс пользователя.

  • Рекомендация 3 - Развертывание приложения должно выполняться в среде с несколькими зонами доступности, для повышения этого показателя.

Резюме

После проверки результатов оценки TARA вы увидите слабые места системы. Сможете предположить, какой объем работы необходим для улучшения системы и каких технических знаний не хватает в команде разработчиков. Каковы были ожидания или недопонимания, которые привели к неправильной имплементации?

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


Материал подготовлен в преддверии старта курса «Enterprise Architect».

Всех желающих приглашаем на demo-занятие «Информационная архитектура компании». На занятии мы изучим слой информационной архитектуры, поймем её место и взаимосвязи в модели BIAT (Business, Information, Application, Technology).
В качестве базы посмотрим в целом на управление данными в соответствии с DMBok и обратим внимание на важность и эволюцию практики Data governance.
Далее автор разберет основы концептуального моделирования и расскажет о некоторых полезных фреймворках.
Посмотрим, как информационная архитектура помогает выделять контексты на разных уровнях проектирования от программного до организационного.
>> РЕГИСТРАЦИЯ

Источник: https://habr.com/ru/company/otus/blog/588392/


Интересные статьи

Интересные статьи

Служба техподдержки в крупной компании обычно обслуживает целый зоопарк сервисов, например: пару виртуальных АТС, онлайн-магазин, умный дом и охранную систему в придачу. У ребят всег...
Уже давольно давно, вдохновившись статьей Ресайз изображений на лету был настроен ресайз изображений с помощью ngx_http_image_filter_module и все работало как надо. Но появилась одна проблема, ко...
Приветствую, Хабр! Предлагаю вашему вниманию небольшую пятничную статью про Java, Scala, ненормальных программистов и нарушенные обещания. Простые наблюдения иногда приводят к не очень простым...
В 2019 году люди знакомятся с брендом, выбирают и, что самое главное, ПОКУПАЮТ через интернет. Сегодня практически у любого бизнеса есть свой сайт — от личных блогов, зарабатывающих на рекламе, до инт...
О том, что производители разного рода девайсов основное внимание уделяют дизайну и удобству пользования, оставляя вопросы информационной безопасности за бортом, на Хабре писали много раз. Это...