Skip to content
This repository has been archived by the owner on Jun 20, 2023. It is now read-only.

Feature/TASK 3483 risk calculation v2 #1457

Merged

Conversation

nickguendling
Copy link
Contributor

Description

This implements the pure new risk calculation based on exposure windows including unit tests that are needed test date from a json file. In addition, the exposure notification framework version is set to 2 and the deployment target is set to 13.7 in preparation for the use of exposure windows. The generated protobuf model will regenerated and put into the correct location in the next pull request.

Tech Spec

https://github.com/corona-warn-app/cwa-app-tech-spec/blob/7779cabcff42afb437f743f1d9e35592ef989c52/docs/spec/exposure-windows.md

Jira

https://jira-ibs.wbs.net.sap/browse/EXPOSUREAPP-2582

@nickguendling nickguendling added this to the v1.8.0 milestone Nov 4, 2020
@nickguendling nickguendling requested a review from a team November 4, 2020 11:09
Copy link
Contributor

@whiskey whiskey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comments in RiskCalculationV2 and the RiskCalculationWindow.

Comment on lines 33 to 39
// MARK: - Internal

let min: Double
let max: Double

let minExclusive: Bool?
let maxExclusive: Bool?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats not internal but quite public ;)
Could you add comments on these properties. Are minExclusive and maxExclusive set externally?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, they were indeed internal since that is the default visibility in Swift, not public. But since they are not written or read externally we changed them to private now 🤓👍

@nickguendling nickguendling changed the title Feature/3544 test json parsing Feature/TASK 3483 risk calculation v2 Nov 4, 2020
Copy link
Member

@mlenkeit mlenkeit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good in general. Some minor remarks, mostly around naming 👍


import Foundation

struct CWARange: Decodable {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have automated tests specifically for CWARange?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we do 😁

Comment on lines 52 to 66
var ageInDaysOfMostRecentDateWithLowRisk: Int? {
guard let mostRecentDateWithLowRisk = mostRecentDateWithLowRisk else {
return nil
}

return Calendar.current.dateComponents([.day], from: mostRecentDateWithLowRisk, to: Date()).day
}

var ageInDaysOfMostRecentDateWithHighRisk: Int? {
guard let mostRecentDateWithHighRisk = mostRecentDateWithHighRisk else {
return nil
}

return Calendar.current.dateComponents([.day], from: mostRecentDateWithHighRisk, to: Date()).day
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two are only used for the unit tests to make them independent of specific dates, right? Can we move this into the test coding?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


import Foundation

final class RiskCalculationV2 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure how namespaces work in Swift, but does this have to have V2 in its name, it the folder has it already?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't care about folders 🤡 So yes, having a dedicated V2 helps – unless we use Swift Packages…

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to keep V2 naming for now, will rename it once we have removed the old implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification. If it was for me, you can also keep it permanently, even after the merge.


/// Determines the risk level for one exposure window
/// https://github.com/corona-warn-app/cwa-app-tech-spec/blob/7779cabcff42afb437f743f1d9e35592ef989c52/docs/spec/exposure-windows.md#determine-risk-level-for-exposure-windows
final class RiskCalculationWindow {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not overly happy with the name of this. I would suggest to avoid using the term Window outside of ExposureWindow unless really necessary. How about ExposureWindowRiskAssessment? Or ExposureWindowRiskWrapper?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the caller context the window naming feels the most logical to us. If we rename this, we would have filteredExposureWindowRiskAssessments and exposureWindowsRiskAssessmentsPerDate or something similar.

Copy link
Member

@mlenkeit mlenkeit Nov 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, but then you should also have e.g.filteredRiskCalculationWindows. Would ExposureWindowRiskWrapper or ExposureWindowCalculationWrapper be so bad? If it's "just a wrapper", I think calling variables filteredExposureWindows is still fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could go the other direction and make it an exposure window using the decorator pattern. We gave it a try and called it RiskCalculationExposureWindow and think this accurately describes the exposure window that is extended with risk calculation features. What do you think about this approach?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine for me 👍

Copy link
Member

@mlenkeit mlenkeit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM from architecture side!

@nickguendling nickguendling merged commit 7787f4a into feature/2582-risk-calculation-v2 Nov 5, 2020
@nickguendling nickguendling deleted the feature/3544-test_json_parsing branch November 5, 2020 15:30
@kaddaSz kaddaSz added the task part of a feature label Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature task part of a feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants