Контрольные вопросы
Какие факторы объектно-ориентированных систем влияют на метрики для их оценки и как проявляется это влияние?
Какое влияние оказывает наследование на связность классов?
Охарактеризуйте метрики связности классов по данным.
Охарактеризуйте метрики связности классов по методам.
Какие характеристики объектно-ориентированных систем ухудшают сцепление классов?
Объясните, как определить сцепление классов с помощью метрики «зависимость изменения между классами».
Поясните смысл метрики локальности данных.
Какие метрики входят в набор Чидамбера и Кемерера? Какие задачи они решают?
Как можно подсчитывать количество методов в классе?
Какие метрики Чидамбера и Кемерера оценивают сцепление классов? Поясните их смысл.
Какая метрика Чидамбера и Кемерера оценивает связность класса? Поясните ее смысл.
Как добиться независимости метрики WMC от реализации?
Как можно оценить информационную закрытость класса?
Сравните наборы Чидамбера-Кемерера и Лоренца-Кидда. Чем они похожи? В чем различие?
На какие цели ориентирован набор метрик Фернандо Абреу?
Охарактеризуйте состав набора метрик Фернандо Абреу.
Сравните наборы Чидамбера-Кемерера и Фернандо Абреу. Чем они похожи? В чем различие?
Сравните наборы Лоренца-Кидда и Фернандо Абреу. Чем они похожи? В чем различие?
Дайте характеристику метрик для объектно-ориентированного тестирования.
Глава 15. Унифицированный процесс разработки объектно-ориентированных пс
В первой главе рассматривались основы организации процессов разработки ПО. В данной главе внимание сосредоточено на детальном обсуждении унифицированного процесса разработки объектно-ориентированного ПО, на базе которого возможно построение самых разнообразных схем конструирования программных приложений. Далее описывается содержание ХР-процесса экстремальной разработки, являющегося носителем адаптивной технологии, применяемой в условиях частого изменения требований заказчика.
Эволюционно-инкрементная организация жизненного цикла разработки
Рассматриваемый подход является развитием спиральной модели Боэма [8], [40], [44], [57]. В этом случае процесс разработки программной системы организуется в виде эволюционно-инкрементного жизненного цикла. Эволюционная составляющая цикла основывается на доопределении требований в ходе работы, инкрементная составляющая — на планомерном приращении реализации требований.
В этом цикле разработка представляется как серия итераций, результаты которых развиваются от начального макета до конечной системы. Каждая итерация включает сбор требований, анализ, проектирование, реализацию и тестирование. Предполагается, что вначале известны не все требования, их дополнение и изменение осуществляется на всех итерациях жизненного цикла. Структура типовой итерации показана на рис. 15.1.
Видно, что критерием управления этим жизненным циклом является уменьшение риска. Работа начинается с оценки начального риска. В ходе выполнения каждой итерации риск пересматривается. Риск связывается с каждой итерацией так, что ее успешное завершение уменьшает риск. План последовательности реализаций гарантирует, что наибольший риск устраняется в первую очередь.
Такая методика построения системы нацелена на выявление и уменьшение риска в самом начале жизненного цикла. В итоге минимизируются затраты на уменьшение риска.
Рис. 15.1. Типовая итерация эволюционно-инкрементного жизненного цикла
Рис. 15.2. Два измерения унифицированного процесса разработки
Как показано на рис. 15.2, в структуре унифицированного процесса разработки выделяют два измерения:
горизонтальная ось представляет время и демонстрирует характеристики жизненного цикла процесса;
вертикальная ось представляет рабочие потоки процесса, которые являются логическими группировками действий.
Первое измерение задает динамический аспект развития процесса в терминах циклов, этапов, итераций и контрольных вех. Второе измерение задает статический аспект процесса в терминах компонентов процесса, рабочих потоков, приводящих к выработке искусственных объектов (артефактов), и участников.