Змеев О.А. Архитектурно-центрированный процесс

«Введение в Унифицированный
процесс разработки ПО».
Лекция № 5.
Есть три кита и больше ни черта …
Строки из песенки к фильму «Трест, который
лопнул …»
Кит под номером два.
Архитектурно-центрированный процесс:
Варианты использования – это конечно хорошо, но маловато будет …
Нужно еще кое-что. И это
Архитектура – это некоторое единое представление о
разрабатываемой системе, с которым должны согласиться (или на
худой конец смириться) все сотрудники (то есть разработчики), а
желательно, еще и другие заинтересованные лица.
Архитектура дает нам ясное представление о системе в целом
необходимое для управления ее разработкой.
Архитектура описывает наиболее важные элементы моделей:
 Эти элементы направляют разработку в текущем цикле разработке
и в течение всего жизненного цикла,
 Это некоторые подсистемы, зависимости, интерфейсы, узлы,
кооперации, классы.
Кит под номером два.
Архитектурно-центрированный процесс:
Еще раз про то, что же такое архитектура:
Вспоминаем, про виды с разных сторон – притча о слепых и слоне …
Программная система единая сущность, но разработчики ПО
рассматривают ее с различных сторон зрения, эти точки зрения
называются представлениями или видами.
Архитектура информационной системы включает в себя данные:
 об организации программной системы,
 о структурных элементах, входящих в систему и их интерфейсах, а
также их поведении, которые определяются кооперациями, в
которых участвуют элементы,
 о составе структурных элементов и элементов поведения
наиболее крупных подсистем,
 о стиле архитектуры, принятом в команде разработчиков или
данной организации – элементах, и их интерфейсах, их
кооперации и композиции.
Кит под номером два.
Архитектурно-центрированный процесс:
Кроме структуры и поведения:
 удобство использования,
 функциональность,
 производительность,
 гибкость,
 возможность повторного использования,
 комплексности,
 экономическим и технологическим ограничениям,
 выгодности производства,
 эстетики.
Архитектура определяется представлениями моделей: вариантов
использования, анализа, проектирования и т.д. (Вид 4+1)
Кит под номером два.
Архитектурно-центрированный процесс:
Зачем нужна архитектура?
Необходимость архитектуры является следствием размера и
сложности современных систем , так как «проблема
проектирования находится вне алгоритмов и структур данных:
проектирование и определение общей структуры приложений
является проблемой иного типа».
Архитектура нужна для решения четырех задач:
1.
понять систему,
2.
организовать разработку,
3.
способствовать повторному использованию всего, что можно
использовать повторно (кода и дизайна),
4.
развивать систему в дальнейшем.
Понеслись конкретно по каждой задаче.
Кит под номером два.
Архитектурно-центрированный процесс:
Задача №1. Понять систему. Это проблематично:

Они реализуют сложное поведение.

Они работают в сложном окружении.

Они сложны технологически.

Они часто сочетают распределенные вычисления, коммерческие
платформы и продукты, многократно используемые компоненты
и структуры.
Архитектурно-центрированная

Они должны удовлетворять запросам
как–отдельных
, так
разработка
в контекстелюдей
жизненного
цикла программного обеспечения
и целых организаций.
означает,
что архитектура
системы

В некоторых случаях они настолько
велики,
что их разработку
используется в качестве первичного
приходится разбивать на несколько
мелких проектов.
артефакта для построения концепции,
Выполняемых в разных местах исоздания,
(или) в разное
время.
управления и развития
А еще они постоянно меняются …
системы в ходе ее разработки
Способ предотвратить потерю понятности – архитектурноцентрированная разработка
Кит под номером два.
Архитектурно-центрированный процесс:
Задача № 2. Организовать разработку:
Проблема: число возможных путей коммуникации между членами команд
с увеличением размера команды растет в геометрической
прогрессии.
Команда разработчиков
Команда разработчиков
Команда разработчиков
Команда разработчиков
Кит под номером два.
Архитектурно-центрированный процесс:
Организация вокруг архитектуры радикально снижает число путей
коммуникации. Проблемы, касающиеся взаимодействия подсистем,
решаются архитектором, который владеет интерфейсами между
подсистемами.
Команда разработчиков
Команда разработчиков
Архитекторы
Команда разработчиков
Команда разработчиков
Задача № 3. Повторное использование:
Хорошая архитектура четкий базис, опираясь на который можно топать
дальше … виды архитектур – это один из первых стандартов в
проектировании.
Задача № 4. Повторное использование:
Способность к аккуратному развитию.
Варианты
использования
Архитектура
Опыт
Архитектура предыдущих проектов.
Шаблоны архитектуры.
Системное программное обеспечение.
Средний уровень, в том числе каркасы
программных систем.
Унаследованные системы.
Стандарты и правила.
Нефункциональные требования.
Требования к распространению.
Кит под номером три.
Итеративный и инкрементный процесс:
Предлагает «съесть слона. Как? Да по частям!». Или стратегия
процесса разработки:

Планируем маленький кусочек.

Специфицируем, проектируем и реализуем этот маленький
кусочек.

Собираем, тестируем и запускаем маленький кусочек.

Анализируем что получилось и определяем следующий
маленький кусочек.
Результат: жизненный цикл состоит из последовательности итераций
(определенный набор деятельностей, проводимый в
соответствии с планом и критериями оценки и приводящий к
появлению выпуска внутреннего или внешнего). Результат
итерации – инкремент-приращение.
Кит под номером три.
Итеративный и инкрементный процесс:
Итеративный жизненный цикл не является:

Случайным блужданием.

Это не песочница для разработчиков.

Это не вещь интересная только для разработчиков.

Это не процесс переписывания кода до тех пор, пока
разработчики наконец не напишут что-то приемлемое.

Он не непредсказуем.

Он не может послужить оправданием промахов в планировании
и управлении.
Итеративную и инкрементную разработку используют по следующим
причинам: В трех словах – программы получаются лучше.
Немного более подробно – чтобы пройти главные и
вспомогательные контрольные точки, по которым команда
контролирует ход разработки. Ну и
Кит под номером три.
Итеративный и инкрементный процесс:
Совсем подробно:

Чтобы как можно раньше получить описание критических и
опасных рисков.

Чтобы определить архитектуру для разрабатываемого
программного обеспечения.

Чтобы обеспечить каркас, который наилучшим образом
поддерживает неизбежно появляющиеся в ходе разработки
новые требования и другие изменения.

Чтобы создавать систему в несколько приемов путем
приращений (инкрементов), а не всю сразу оптом, что снижает
стоимость изменений.

Чтобы обеспечить процесс разработки, который повышает
эффективность использования сотрудников.
Системный
аналитик
Найти актеров и
варианты
использования
Планировать
тестирование
Структурировать
модель ВИ
Разработать
тест
Оценить результаты
тестирования
Инженер по
тестированию
Определение
требований
Спецификатор ВИ
Тестирование
Детализировать
варианты
использования
Интегрировать
систему
Системный
интегратор
Реализация
Разработать
интерфейс
пользователя
Разработчик GUI
Провести
тестирование
целостности
Тестер
целостности
Проектирование
Архитектор
Раставить ВИ по
приоритетам
Анализировать
архитектуру
Проектировать
архитектуру
Провести
системные
тесты
Реализовать
архитектуру
Системный
тестор
Анализ
Аналитик ВИ
Разработчик ПО
Анализировать
вариант
использования
Анализировать
класс
Анализировать
пакет
Проектировать
вариант
использования
Проектировать
класс
Реализовать
класс
Проектировать
подсистему
Реализовать
подсистему
Реализовать
тест
Провести
тестирование
модулей