
- •Архитектура ПО
- •Архитектура ПО
- •То есть архитектура – это сквозная концепция или набор таковых для преодоления энтропии
- •При разработке архитектуры ПО важным оказывается совмещение множества точек зрения. ПО оказывается настолько
- •Причина множественности точек зрения при разработке ПО
- •Это происходит, прежде всего, из-за разных видов деятельности процесса разработки ПО (см. рис.
- •Разные виды деятельности – разные взгляды на систему
- •Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов: программисты, инженеры, тестеры,
- •Разные специалисты – разные взгляды на систему
- •Множественность точек зрения происходит также от того, что нет единых стандартов и норм
- •Точка зрения (viewpoint) —
- •Часто понятие архитектуры сильно сужают, понимая под ним лишь описание основных, важных аспектов
- •Диаграмма классов
- •Пример диаграмм размещений
- •Пример диаграмм компонент
- •Управление
- •Требования можно разделить на 2 группы – функциональные и нефункциональные.
- •Свойства требований
- •Свойства требований (продолжение)
- •Варианты формализации требований
- •1.Неформальная постановка требований в переписке по электронной почте.
- •2.Требования в виде документа – описание предметной области и ее свойств, техническое задание
- •3.Требования в виде графа с зависимостями в одном из средств поддержки требований (IBM
- •1.Формальная модель требований для верификации, модельно-
- •Цикл работы с требованиями
- •2.Анализ требований (requirements analysis), целью которого обнаружение и устранение противоречий и неоднозначностей в
- •4.Валидация требований (requirements validation), которая решает задачу оценки понятности сформулированных требований и их

Точка зрения (viewpoint) —
это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта.
Важнейшими характеристиками точки зрения моделирования является цель
(зачем создается модель) и целевая аудитория (то есть, для кого она предназначается).
11

Часто понятие архитектуры сильно сужают, понимая под ним лишь описание основных, важных аспектов ПО, создаваемых, например, архитектором при разработке дизайна системы. Для
этих целей используется язык моделирования UML (Unified Modeling Language).
12

UML
13

Диаграмма классов
14

Пример диаграмм размещений
15

Пример диаграмм компонент
16

Управление
требованиями
17

Требования можно разделить на 2 группы – функциональные и нефункциональные.
1.Функциональные требования являются детальным описанием поведения и сервисов системы, ее функционала. Они определяют то, что система должна уметь делать.
2.Нефункциональные требования не являются описанием
функций системы. Этот вид требований описывает такие характеристики системы, как надежность, особенности поставки (наличие инсталлятора, документации), определенный уровень качества. Сюда же могут относиться требования на средства и процесс разработки системы, требования к переносимости, соответствию стандартам и т.д.
18

Свойства требований
1.Ясность, недвусмысленность — однозначность понимания требований
заказчиком и разработчиками.
2.Полнота и непротиворечивость
3.Необходимый уровень детализации. Требования должны обладать ясно
осознаваемым уровнем детализации, стилем описания, способом формализации.
19

Свойства требований (продолжение)
4.Прослеживаемость — важно видеть то или иное требование в различных моделях, документах, наконец, в коде системы.
5.Тестируемость и проверяемость — необходимо, чтобы существовали способы
тестировать и проверить данное требование.
6.Модифицируемость. Определяет процедуры внесения изменений в требования
20