Как измерить производительность и ремонтопригодность системы на диаграмме классов UML?

Question

Сейчас я делаю тестовый раздел UML, я понимаю, что вообще означают производительность и ремонтопригодность, но я не понимаю, как оценивать их с помощью диаграммы классов UML. Тестовый вопрос:

Рассмотрим модель, изображенную на диаграмме классов UML в следующий рисунок.

Теперь рассмотрим изменение модели с точки зрения добавления промежуточного итога. атрибут (со значением article.getPrice () * количество) и get метод для этого к классу OrderLine и использование его в getTotal (). Какое влияние это изменение окажет на нефункциональные свойства система?

A) худшая производительность Order.getTotal (), лучшая ремонтопригодность системы

B) лучшая производительность Order.getTotal (), худшая ремонтопригодность системы

C) без эффекта

D) худшая производительность Order.getTotal (), худшая ремонтопригодность системы

E) лучшая производительность Order.getTotal (), лучшая ремонтопригодность системы

Правильный ответ здесь: поэтому, пожалуйста, объясните, как прийти к этому ответу.

Спасибо.

Answer 1

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

Производительность будет хуже в сценарии 2, поскольку (вероятные) оптимизации компилятора будут означать, что вызовы getArticle (). GetPrice () и getQuantity () оптимизировать так же, как , напрямую получая доступ к цене и количеству переменных в памяти (будучи примитивами , они будутв стеке , предполагая, что эти методы get являются простыми средствами доступа), тогда как subTotal () не будет оптимизировать таким образом, поскольку это не простой метод доступа (т.е.он содержит саму логику), что означает, что вы вынуждены проходить к куче (где живут экземпляры OrderLine), чтобы получить доступ к переменным price . Доступ к стеку намного быстрее, чем кучи.

Таким образом, в сценарии 1 переменные цены и количества доступны непосредственно в стеке с помощью цикла в Order.В сценарии 2 вы заставляете указатель / указатель перемещаться в кучу из-за вызова метода subTotal (), который требует времени для обработки, хотя и незначительной разницы в реальности для сегодняшних скоростей процессора и шины памяти.

Стек = примитивы (то есть цена, количество) и ссылки / указатели.Куча = объекты (т.е. экземпляры Order, OrderLine и Article).

Answer 2

Я думаю, что C - правильный ответ.Исходная ситуация состоит в том, что Order получает доступ к OrderLine для получения количества и через тот же объект получает доступ к Article для цены.С этими значениями он выполняет умножение (в пределах цикла суммирования).Теперь в новой ситуации он вызывает subtotal из Order, который сам должен получить доступ к Article по цене, и это вернет результат умножения.Так что с точки зрения производительности нет абсолютно никакой разницы.С точки зрения удобства обслуживания subtotal может быть лучшим подходом, хотя его преимущество в том, чтобы скрыть умножение, кажется, все равно не заметно.