Вообще у меня есть серьёзные сомнения насчёт уместности термина "Анализ Приложения", о чём в принципе немного упоминают и авторы. Анализировать, на мой взгляд, можно только нечто существующее, как-то - Предметную область, Требования, Систему. Если же системы нет, она только создаётся, то можно её только синтезировать, проектировать, конструировать, но не анализировать.
Возможно тут проблемы перевода, возможно и нет. На мой не оченьискушенный взгляд, термин анализ тут применяется как системный анализ. Безусловно разработка приложения есть суть синтеза анализируемого решения. Под анализом же здесь понимается процедура формирования решения. Т.е. решение синтезируется на основании анализа, а анализ преполагает детальное рассмотрение.
Вообще не стоит путать понятие дейтельности, артефактов с собственно с моделью. Авторя ясно и многократно повторяют: есть три модели, три напраления моделирование: моделирование и модель структуры, модель состояний и модель взаимодействия.
Этапы изучения будущей системы или существующей проходят через разные уровни: концептуализация, формализация, проектирование, конструирование. Каждый этот уровень предполагает потребность, необходимость формирования всестороннего рассмотрения системы на этом уровне через построение 3 базовых моделей в той или иной степени детальности (зависит от уровня).
Таким образом этап деятельности называемый анализом ПрОб включает по замыслу авторов все три модели - модель структуры, модель состояний и модель взаимодествий ( в оригинале последняя молдеь не раскрывается - как не важная в данном цикле задач). Авторы конечно употребляют понятие модели предметной области, которая состоит из трех сторон - основная мысль авторов - избегать использования понятий, элементов и т.п. реализации.
На этапе анализа приложения формируется модель приложения, т.е. читай системы. Здесь по мнению авторов важным становится взаимодействие частей системы между сосбой и внешними пользователями. На данном этапе анализ продалжается, но уже сосредоточен на событиях, которые должны возникать при эксплуатации системы, при удовлетворении потребностей пользователей. Выделяются, обнаруживаются, понимаются, детализируются, то есть АНАЛИЗИРУЮТСЯ внешние события, нетипичные сценарии, исключительные ситуации, произовдится структуризация взаимодейстивия (что очень правильно, ибо на стади анализа предметной области такая структуризация будет только вредить и усложнять понимание, а на стадии анализа приложения - это уже внутреняя работа разработчика). Синтез никогда не происходит без анализа. Заметь у автора везде указывается: проверка того-то по тому-то, а проверка разве не есть анализ?
Кроме того анализируется как раз НЕЧТО существующее, т.е. некоторое умозрительное представление
Книги: UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.