Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру 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.
Далее автор разберет основы концептуального моделирования и расскажет о некоторых полезных фреймворках.
Посмотрим, как информационная архитектура помогает выделять контексты на разных уровнях проектирования от программного до организационного.
>> РЕГИСТРАЦИЯ
