8.Какие метрики входят в набор Чидамбера и Кемерера? Какие задачи они решают?

9.Как можно подсчитывать количество методов в классе?

10.Какие метрики Чидамбера и Кемерера оценивают сцепление классов? Поясните их смысл.

11.Какая метрика Чидамбера и Кемерера оценивает связность класса? Поясните ее смысл.

12.Как добиться независимости метрики WMC от реализации?

13.Как можно оценить информационную закрытость класса?

14.Сравните наборы Чидамбера-Кемерера и Лоренца-Кидда. Чем они похожи? В чем различие?

15.На какие цели ориентирован набор метрик Фернандо Абреу?

16.Охарактеризуйте состав набора метрик Фернандо Абреу.

17.Сравните наборы Чидамбера-Кемерера и Фернандо Абреу. Чем они похожи? В чем различие?

18.Сравните наборы Лоренца-Кидда и Фернандо Абреу. Чем они похожи? В чем различие?

19.Дайте характеристику метрик для объектно-ориентированного тестирования.

ГЛАВА 15. УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ОБЪЕКТНООРИЕНТИРОВАННЫХ ПС

В первой главе рассматривались основы организации процессов разработки ПО. В данной главе внимание сосредоточено на детальном обсуждении унифицированного процесса разработки объектноориентированного ПО, на базе которого возможно построение самых разнообразных схем конструирования программных приложений. Далее описывается содержание ХР-процесса экстремальной разработки, являющегося носителем адаптивной технологии, применяемой в условиях частого изменения требований заказчика.

Эволюционно-инкрементная организация жизненного цикла разработки

Рассматриваемый подход является развитием спиральной модели Боэма [8], [40], [44], [57]. В этом случае процесс разработки программной системы организуется в виде эволюционно-инкрементного жизненного цикла. Эволюционная составляющая цикла основывается на доопределении требований в ходе работы, инкрементная составляющая — на планомерном приращении реализации требований.

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

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

Такая методика построения системы нацелена на выявление и уменьшение риска в самом начале жизненного цикла. В итоге минимизируются затраты на уменьшение риска.

Рис. 15.1. Типовая итерация эволюционно-инкрементного жизненного цикла

212

Рабочие потоки процесса имеют следующее содержание:

Сбор требований — описание того, что система должна делать;

Анализ — преобразование требований к системе в классы и объекты, выявляемые в предметной области;

Проектирование — создание статического и динамического представления системы, выполняющего выявленные требования и являющегося эскизом реализации;

Реализация — производство программного кода, который превращается в исполняемую систему;

Тестирование — проверка всей системы в целом.

Каждый рабочий поток определяет набор связанных артефактов и действий. Артефакт — это документ, отчет или выполняемый элемент. Артефакт может вырабатываться, обрабатываться или потребляться. Действие описывает задачи — шаги обдумывания, шаги исполнения и шаги проверки. Шаги выполняются участниками процесса (для создания или модификации артефактов).

Между артефактами потоков существуют зависимости. Например, модель Use Case, генерируемая в ходе сбора требований, уточняется моделью анализа из процесса анализа, обеспечивается проектной моделью из процесса проектирования, реализуется моделью реализации из процесса реализации и проверяется тестовой моделью из процесса тестирования.

Модели

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

бизнес-модель. Определяет абстракцию организации, для которой создается система;

модель области определения. Фиксирует контекстное окружение системы;

модель Use Case. Определяет функциональные требования к системе;

модель анализа. Интерпретирует требования к системе в терминах проектной модели;

проектная модель. Определяет словарь проблемы и ее решение;

модель размещения. Определяет аппаратную топологию, в которой исполняется система;

модель реализации. Определяет части, которые используются для сборки и реализации физической системы;

тестовая модель. Определяет тестовые варианты для проверки системы;

модель процессов. Определяет параллелизм в системе и механизмы синхронизации.

Технические артефакты

Технические артефакты подразделяются на четыре основных набора:

набор требований. Описывает, что должна делать система;

набор проектирования. Описывает, как должна быть сконструирована система;

набор реализации. Описывает сборку разработанных программных компонентов;

набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.

Набор требований группирует всю информацию о том, что система должна делать. Он может включать модель Use Case, модель нефункциональных требований, модель области определения, модель анализа, а также другие формы выражения нужд пользователя.

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

Он может включать проектную модель, тестовую модель и другие формы выражения сущности системы (например, макеты).

Набор реализации группирует все данные о программных элементах, образующих систему (программный код, файлы конфигурации, файлы данных, программные компоненты, информацию о сборке системы).

Набор размещения группирует всю информацию об упаковке, отправке, установке и запуске системы.

214