3.10.1. Оценки разработчиков возможности проверки требований

• Система должна отвечать на произвольный запрос в течение 500 миллисекунд. Все зависит от того, что подразумевается под словом произвольный, если число запросов конечно, и можно выявить наиболее сложные из них, проверка возможна;

• Цифры на экране, показывающем время, должны хорошо выглядеть. Красота — дело вкуса, проверить нельзя;

• Система должна быть дружественной пользователю. Требование неконкретно, в таком виде непроверяемо;

• Система должна экспортировать данные для просмотра в формате, в котором в качестве разделителя используется запятая. Надо уточнить некоторые детали, например, что будет, если данные представляют пустое множество, в этом случае требование проверяемо.

3.11. Определение приоритетов

Необходимо устанавливать для того, чтобы оптимальным образом планировать выпуски ПО. Приоритеты требования устанавливаются экспертами. Самая простая методика:

Методика MoSCoW

• Обязательные для выполнения (Must).

• Должны быть сделаны (Should).

• Могут быть сделаны (Could).

• Не нужны (Won't).

Методика определения по срочности и важности

-----------------------------------------------------------------------------------

Важные Неважные

------------------------------------------------------------------------------------

Срочные Высокий приоритет Не занимайтесь им!

Не срочные Средний приоритет Низкий приоритет

3.12. Определение приоритета по полезности (ценности) функции

Методика вычисления относительной полезности функции для пользователя Quality Function Deployment (QFD).

Оценки выгоды, урона, стоимости, риска — от 1 (минимально) до 9 (максимально)

Приоритет = % ценности / (%стоимости * вес_стоимости + %риска * вес_риска).

Лекция 4. Средства анализа требований к ПО. Основы UML

4.1. Стандарты языка UML

Язык UML — Unified Modeling Language.

Авторы: Гради Буч, Джеймс Румбо, Айвар Якобсон.

UML 2.4.1 (2011) принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2:2012.

Спецификации UML:

• 1.3 (1999 год)

• 1.4 (2001 год)

• 1.5 (2003 год)

• 2.0 (2005 год)

• 2.5 (март 2015 года)

• 2.5.1 (декабрь 2017)

UML движется в сторону упрощения.

Официальный сайт: www.omg.org

4.2. Назначение и элементы UML

• Используется для анализа, проектирования, документирования ПО.

• Модели UML могут быть переведены на языки программирования (C++, Java, Visual Basic, и др.).

• Элементы UML:

  • диаграммы,

  • предметы (диаграммы строятся из предметов — сущностей; различают структурные [например, класс/компонент] и предметы поведения [например, действие]),

  • отношения (схематическая связь между объектами).

4.3. Диаграммы uml (uml 2.5)

Структурные диаграммы (не меняются в процессе эксплуатации):

• Диаграмма классов.

• Диаграмма компонентов (компонент — любой файл; например, файл с исходным кодом, исполняемый файл, файл с данными).

• Диаграмма пакетов (например, с точки зрения Java, пакет — директория, которая хранит другие директории и java-файлы).

• Диаграмма профилей (связано с пользователями).

• Диаграмма объектов (отражает набор объектов и их взаимодействий).

• Диаграмма композитной структуры (тоже показывает взаимодействия сущностей программного продукта).

• Диаграмма развертывания (для иллюстрации информационной системы; компоненты инфраструктуры, компоненты оборудования).

Диаграммы поведения (могут меняться в процессе эксплуатации):

• Диаграмма прецедентов (отображает основные функции ПО).

• Диаграмма деятельности (отображает процесс исполнения сценария варианта использования).

• Диаграмма состояний (иллюстрация объекта, который имеет ограниченное число состояний; конечный автомат).

• Диаграммы взаимодействия (относятся к диаграммам поведения):

  • Диаграмма последовательности.

  • Диаграмма коммуникаций.

  • Диаграмма обзора взаимодействия.

  • Диаграмма синхронизации.

4.4. Структурные диаграммы (Structure Diagrams)

• Class diagram — диаграмма классов.

• Component diagram — диаграмма компонентов.

• Composite structure diagram — диаграмма композитной/составной структуры.

• Collaboration (UML 2.0) — диаграмма кооперации.

• Deployment diagram — диаграмма развертывания.

• Object diagram — диаграмма объектов.

• Package diagram — диаграмма пакетов.

• Profile diagram (UML 2.2) — диаграмма профилей.

4.5. Диаграммы поведения (Behavior Diagrams)

• Activity diagram — диаграмма деятельности.

• State Machine diagram — диаграмма состояний.

• Use case diagram — диаграмма прецедентов.

4.6. Диаграммы взаимодействия (Interaction Diagrams)

Communication diagram (UML2.0) / Collaboration (UML 1.x).

Диаграмма коммуникации (UML 2.0) / диаграмма кооперации (UML 1.x).

Interaction overview diagram (UML 2.0) — диаграмма обзора взаимодействия.

Sequence diagram — диаграмма последовательности.

Timing diagram (UML 2.0) — диаграмма синхронизации.

4.7. Структурные предметы UML

• Класс (помимо приведенных трех частей, может быть четвертая с примечаниями; + — public доступ, - — private доступ, # — protected доступ)

• Объект (паскалевская нотация)

• Кооперация (сотрудничество)

• Актер (вне ПО, взаимодействующий с ним)

• Прецедент (Use Case / Вариант Использования; имя прецедента лучше обозначать глаголом, например, «сохранить данные»)

• Интерфейс

• Активный класс (содержит в себе поток обработки сообщений)

• Компонент UML 1.2

• Компонент UML 2.0

• Узел

• Пакет

• Комментарии (аннотации)