Гораздо лучше обнаружить недостающую спальню, пока архитектура является только чертежом, а не в день переезда. (Paul Clements) При оценке архитектуры программного обеспечения вы пытаетесь найти проблемы в архитектуре / имплементации. Когда вы можете это сделать? Поиск ошибок на ранней стадии во время проектирования Во время разработки, чтобы сравнить реализацию с проектом В процессе технического обслуживания и дальнейшего развития. На практике оценка чаще всего проводится после того, как имплементация завершена и проект уже находится в производстве. Метод небольшого архитектурного обзора (TARA) был изобретен для ситуаций, когда исчерпывающий метод неприменим. TARA не основан на сценариях, как методы типа ATAM, а опирается на промышленный опыт. Он гибкий и простой в использовании. TARA сэкономит ваше время и ресурсы. Нет времени и нет возможности использовать сценарный подход. Система уже внедрена Простая оценка, поскольку не требуются другие методы, такие как деревья атрибутов качества, используемые в ATAM Предназначен для одного аудитора без участия многих заинтересованных сторон Может использоваться в качестве первого шага перед применением более детальной оценки, такой как ATAM, для предварительного убеждения компании в преимуществах оценки архитектуры программного обеспечения. 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.Далее автор разберет основы концептуального моделирования и расскажет о некоторых полезных фреймворках.Посмотрим, как информационная архитектура помогает выделять контексты на разных уровнях проектирования от программного до организационного. >> РЕГИСТРАЦИЯ Редактор