Created new military_units_and_combat UML diagram using PlantUML, and fo...

[SamuelFoster]

...llowing UML standards more closely. (Old diagrams kept for information content)

This diagram fits more nicely into the Galactic_State diagram's description of Space and stacks.

This diagram also suggests a change to Galactic_State, where Space can also split and merge stacks.

[SamuelFoster]

I will probably work on adding Military Combat to that diagram tonight

[SamuelFoster]

Also, once I have access to Dr. J's comments, I'll work on implementing those.

[SamuelFoster]

A question about pull request mechanics: if this pull request were merged, would the last three commits be included in that merge? or would it only be the initial commit?

[hallister]

@SamuelFoster Once a PR is merged the PR is closed and no longer updates.

For assignments, I try to keep PR's open until whomever is submitting is happy with it, as it prevents having to constantly open PR's.

[SamuelFoster]

Could someone review this diagram for me?

The basic philosophy behind the current diagram design is that characters and military units are generally organized into stacks, and the interactions (e.g, combat, interception, searching, etc.) are routines performed on the participating stacks.

In this model, most of the information about what a particular military unit can do (the literal 'rules' involving that unit) will be handled by the routines rather than the Unit class itself.

The issues of state (what this Unit is, what Space it's in) are contained in the classes, while the issues of interaction (e.g., how an environ affects military combat) are handled by the routines in a general Combat class which will be responsible for resolving those interactions (as well as containing data like the combat tables).

[thom5468]

@SamuelFoster Just so I'm clear, this is a state diagram and not a redo for the class UMLs right?

[SamuelFoster]

@thom5468 No, this would be a redo of the class UMLs. I think that the old class UMLs, while they contain useful information, don't really represent classes.

I believe the methods of the Combat class would be something to put into state diagrams though.

[thom5468]

@SamuelFoster Before we merge this I would question if using a combination of dia and plant would be appropriate. Your diagram looks excellent and I agree with all of your relationships but for the sake of looking like we have a unified project the UML needs to be done in dia OR the whole group needs to make a switch to plant.

[SamuelFoster]

@thom5468 Well, I personally found PlantUML to be incredibly easy to implement, and I find it makes viewing the differences between commits simpler. I would personally support a group switch to PlantUML (and probably more rigorously following PEP8, but that doesn't need to happen immediately).

If we decide to switch to PlantUML and someone isn't comfortable with PlantUML yet and are too busy to learn it immediately, I could probably migrate their UML diagrams for them.

But I guess if the group decides to stick with dia, I can migrate my diagram back to dia instead.

[thom5468]

@SamuelFoster Alright, I see your perspective. Ultimately, its not my decision. So we will hold onto your PR until we can get more commentary on this issue.

[hallister]

@SamuelFoster I tend to agree PlantUML is far simpler and would prefer moving to it. However, for the time being I think we should stick with Dia and move them all at once instead of one at a time. Just my opinion though.

[Greg-Donaldson]

How do you remove the C from the classes in PlantUML?

[SamuelFoster]

@Greg-Donaldson the line

"hide circle"

removes C's (or any other letter that would be in that circle)