Version 9 (modified by jelinson, 3 years ago) (diff)


Below is a breakdown of the revisions suggested during the architecture design review, separated by changes we did make and changes we did not incorporate.

Changes Accepted ==

Update domain diagrams to include labels between different domains - Must do
The group suggested that our domain diagram include labels to clarify how the different domains relate, so it would be more specific than uniform arrows. We did, updating a few of the domains as well to better reflect the current class structure.

Update sequence diagrams to include where necessary - Should do
The group found the sequence diagrams confusing because one included to indicate the interface between UI and Game but it was absent in others. To account for this, we added where it was needed int the other sequence diagrams. We initially left it out because we thought it might constitute unnecessary detail, but we since added it to ensure clarity.

Changes Not Made ==

Use a unified data object to store all data - Should consider
The group suggested that instead of using State objects to store game data and Window objects to store graphical data we should consider using a single data object type that would retain all information. We did not accomodate this suggestion because we thought it introduced unnecessary coupling between the two types of data and provided no advantage, since our current design requires that most classes have access to only one of those types of data. It also sounded like the class would have to be rather large and bulky. Moreover, the group suggested using a single instance of the data object, which seems like it would require either excessive data transfer between functions or global variables, neither of which sound like good design decisions. Thus we chose not accomodate this suggestion.

Endings that aren't binary win/loss - Should consider
The group suggested considering endings that aren't simply you win or lose. We thought this was indeed a good suggestion. However, we did not feel that incorporating this was an architectural decision, as it did not require any design changes. To implement a score-based ending, it would simply require performing some calculating based on the final state. Nevertheless, this consideration will be revisited, but not through the lens of the game architecture.