Архитектура ПО – набор внутр. структ. ПО, которые рассматривается с разных точек зрения, их связей и возможных взаимодействий между собой.

Диаграмма состояний - содержит состояния конечных автоматов. Конечный автомат содержит состояния определенного объекта и переходы между ними.

Архитектурное проектирование

Архитектура ПО – набор внутр. структ. ПО, которые рассматривается с разных точек зрения, их связей и возможных взаимодействий между собой.

«4+1» :Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования). Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов. Представление разработк. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы. Представление развёртывания. Описывает статическую организацию программной системы в среде разработки. Сценарий представления.

Цели:интеллектуальный контроль, поддержка повторного использования, организация работ в проекте.

Архитектурные стили:Многоуровневая архитектура ( назначение: реализация больших систем, которые имеют большое количество разноплановых элементов; назначение решения: выделить определённый набор уровней, каждый из которых отвечает за решение своих подзадач. шаблон уровня: последовательность уровней, каждый из которых может обращаться только к своему соседнему. + можно легко менять и повторно использовать компоненты; - - изменение одного уровня приводит к каскадному изменению во всех остальных, уровни часто дублирую работу друг друга).

Проектирование ПО: Принцип SOLID (принцип единой ответственности) - не должно существовать больше 1-го мотива для изменения класса. Принцип Open/Close - объекты проектирования должны быть открыты для просмотра и закрыты для модификации. Принцип подстановки – формирование функции, использование ссылки на базовые классы должны иметь возможность использ. объекты произв. классов, не зная об этом. Принцип изоляции интерфейса – говорит о том, что клиент не должен обязательно зависеть от эл. и-са, кот. он использует. Принцип инверсной ответственности – модули верхних уровней не должны зависеть от нижних уровней; оба типа модулей должны завесить от абстракции; абстракция не должна завесить от деталей; детали зависят от абстракции.

Шаблоны проектирования: Информационный эксперт –решает проблему разделения обязанностей и говорит о том, что выполнить обязан должен тот класс, который имеет для этого данные. Шаблон Creator – кто должен создавать шаблоны объекта ( В – созданный экз. класса А, ЕСЛИ: класс В – агрегат для класса А; класс В содержит класс А, если в атрибуте есть класс А; если класс А имеет для инициализацию; если класс В записывает объекты класса А ). Шаблон контроля – разрешает проблему разделения н-са и логики, отвечает за системные соо. Шаблон низкой связности – выполняет разделение обязанностей между классами, чтобы уменьшить связность. Шаблон высокого сцепления – связность и сфокусировка метода класса должна быть максимальной.

Тестиование: «Белый ящик» — тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка на котором она писалась.

Техника тестирования по принципу Белого ящика, также называемая техникой тестирования управляемая логикой программы, позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы.

Техника Белого ящика включает в себя следующие методы тестирования:

покрытие операторов

покрытие решений

покрытие условий

покрытие решений и условий

комбинаторное покрытие условий

Тестирование чёрного ящика или поведенческое тестирование — стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций.

Уровни тестирования: модульное тестирование, тестирование интеграций, системное тестирование. Критерии приёма - программист и заказчик определят готовность принять систему, прописаны системные тесты и критерии, по которым будет принята система. Приёмо-сдаточные тесты – демонстрация того, что делает программа. Планирование тестирования: определить – стратегию тестирования, ограничения по времени и бюджету, ресурсы тестирования, оценка риска невыполнения графика, определение способа документ. тестирования. Принцип разработки стратегии тестирования – необходимо тестировать требования с наивысшим приоритетом в первую очередь; прежде всего тестировать новые функциональные возможности и прог. код, которые меняется с целью усовершенствования или устранения ошибок; использовать разбиение на классы эквивалентности и анализ граничных значений; тестировать те части, в которых наиболее вероятно появление ошибок; сконцентрировать внимание на функциях, с которыми чаще всего будет иметь дело пользователь. Критерии тестирования – критерий входа, критерий выхода, критерий определения дефектов, др. критерии. Планирование тестов: архитектура тестов, определение целей теста, документация тестов. Тест – это набор операций, предназначенный для получения 1-го или нескольких результатов в определённой программной системе. Шаблон записи тестов – название теста, место нахождения теста, цель теста, конфигурация, настройка на прогон теста, методика тестирования, взаимозависимость теста, очистка теста. Критерий выхода из тестирования: выполнить все запланированные тесты, критерий завершения времени тестирования, соотв. Профиля ошибок критерию выхода из тестирования.

Модели разработки ПО:

каскадная модель (модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.),

итерационная модель(проектирования и реализации кода продукта, при котором не вносятся серьёзные изменения в архитектуру, а лишь направляются эволюционные процессы развития),

V- модель(детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы) ,

инкрементная разработка (стратегия планирования стадий проекта, при которой различные части системы разрабатываются в разное время. При инкрементной разработке вся система разбивается на отдельные компоненты или модули, разработка каждого из которых планируется и осуществляется отдельно во времени, с последующей интеграцией в систему по мере готовности.).