Раздаточный 5 / Lecture_05_0_Architecture

Плотников Константин Анатольевич

Ведущий Системный Архитектор

Тема 5: Архитектура ПО и роль Системного Архитектора

Место архитектуры в цикле разработки ПО

Как и зачем описывать архитектуру

Типичные проблемы в архитектуре системы

Обязанности архитектора

Как стать архитектором

2

Нужды – это то, чего хочет заказчик (разница между желаемым и актуальным состоянием системы)

Требования – это внешние ограничения системы (граничные условия)

Архитектура – это общая структура проекта (явная или неявная) и другие технические решения

Исходный код и конфигурация – явная структура проекта, зафиксированная в артефактах (которые могут читать и изменять люди), и прямо влияющая на поставляемый продукт

Поставляемый продукт – то, что ставит у себя заказчик (изменяет нужды)

3

4

Переиспользуемая

Архитектура

Переиспользуемые Код и Конфигурация

5

Аннотация (Executive Summary)

Введение

◦Цель системы

Требования

◦См. предыдущую лекцию

◦Технические Прецеденты (Use Case) и нефункциональные требования

Обзор Архитектуры (Architecture Overview)

◦Диаграмма компонентов (разбиение на высокоуровневые компоненты и связи между ними)

◦Общие архитектурные подходы (Java EE, REST, ESB, и т. д.)

Описание отдельных компонентов и подсистем

◦Важные интерфейсы

◦Сценарии использования и контракты

◦Определение компонентов

Ссылки

6

Помогает координации работы между участниками проекта

Компоненты соответствуют задачам в проекте (размер компонента нижнего уровня: 4-16 часов)

Детализация - достаточная для склейки этого всего вместе, учитывая:

◦Сложность коммуникации (язык, география, время, подчиненность)

◦Опыт команды

Фиксирует важные технические решения в рамках проекта

Живой документ – нужно постоянно поддерживать (особенно в случае распределенных команд)

Если описание архитектуры это часть технического предложения, то входит в состав пакета подписываемых документов.

Служит основой для разбиения на подзадачи и оценки проекта.

7

http://public.dhe.ibm.com/software/dw/libra ry/rational/docs/YummySAD.doc (из статьи Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process)

JSR-000322 JavaTM EE Connector Architecture 1.7 http://download.oracle.com/otndocs/jcp/con nector_architecture-1_7-mrel-eval-spec/

8

Переусложнённость («нам потом это пригодится»)

Переупрощённость («и так пойдет»)

Избыточное переиспользование («Java EE – это стандарт!»)

Недостаточное переиспользование («Not Invented Here»)

Недоопределенность («пойди туда, не зная куда, и принеси то, не знаю что»)

Избыточная детализация («это спецификация с точностью до пикселя!»)

Слишком много новых технологий («зато у нас будет яркая и насыщенная событиями жизнь!»)

Слишком старые технологии («и почему так мало откликов на вакансию программиста на COBOL?»)

9

1.Координация сбора и анализа требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения

2.Разработка требований различных типов к программному изделию

3.Разработка архитектуры системы

4.Разработка концепции реализации системы программного изделия по спецификациям

5.Обеспечение корректности и оптимальности архитектуры проекта

6.Взаимодействие с заказчиком по обсуждению проектных решений

7.Контроль исполнения архитектурных решений

8.Согласование взаимодействий и увязка поведения компонент

9.Участие в оптимизации и исправлении реализованного программного обеспечения

10.Организация и планирование тестирования

11.Контроль проектной и технической документации

12.Участие в документировании проекта

13.Анализ качества продукта и его соответствия требованиям и спецификациям

14.Анализ и совершенствование процесса проекта

15.Участие в планировании проекта

16.Участие в управлении проектом

17.Участие во взаимодействии с заказчиком по вопросам бюджетных расходов и сдачи проекта

18.Участие в работе советов организации

19.Участие в сопровождении программного продукта

20.Обучение и содействие повышению квалификации персонала

21.Саморазвитие

10