Galactic State about class-diagrams HOT 19 CLOSED

@hall5714 Does this also include classes like military units, characters, and sovereigns? Or which team did you envision tackling those?

from class-diagrams.

I think Military Units/Character Combat is going to cover those. But Sovereigns probably would be covered by Galactic State.

from class-diagrams.

Does Galactic State cover PDB's, or are those under Military Units?

from class-diagrams.

@SamuelFoster Hmm... that's a tough one since there is some crossover. But since they are stationary I would say they have more a relationship with the planet they are on. So I'd say more Galactic State. But I'll see if anyone else things so.

from class-diagrams.

I agree with Galactic State, as they cannot be moved, and every planet can be upgraded/downgraded etc. However does this also include atrocity possibilities? Or maybe that will just be a small detail looked over until later on

from class-diagrams.

@crockj72 and @b-cumber I got a question on your diagram. You have an inheritance arrow where space (orbit im assuming) is inheriting all the properties of an environ. I think the relation should be the other way around where environ inherits from space. Let me know if this is true or what your reasoning for that relationship was. please, thank you...

from class-diagrams.

Haha yes it should be, you are right. Sorry about that! Must have spaced

from class-diagrams.

@crockj72 Mkay, just checking. I will take care of the alteration and resubmit.

from class-diagrams.

@thom5468 Now I'm confused. I'm looking at the Git history and not seeing any changes, but Environ is inheriting from Space.

In inheritance the arrow should be at the parent, in aggregation/composition the diamond should be at the aggregate. So did this get fixed and I missed it?

from class-diagrams.

@crockj72 @b-cumber So here's my confusion: Environ inherits from Space but a Planet is an aggregation of Environ and Space.

I think what this should be is this:

Orbit part of System
Planet part of System
Orbit surrounds Planet
Environ part of Planet

part of is composition (An Environ cannot exist without a Planet, etc), rather than aggregation.
surrounds is a user-defined relationship.

If I'm wrong, what attributes and methods do you think planet and orbit share that makes inheritance necessary?

from class-diagrams.

FYI I can make these changes if you have no complaints and we can take another look.

from class-diagrams.

I agree that the associations should be stronger, like that of composition if I understand correctly, but I don't think we need a user-defined "surrounds" because it doesn't have any functionality that requires that. A planet is essentially the sum of 1-3 environs and 1 "space" which must be traveled through to get to any of the environs. But if you have a good mental picture how it would work with "surrounds" then that would be good too!

from class-diagrams.

@crockj72 Surrounds was a lame example.

Okay, so here's my thinking. Is a planet really the sum of environs and a "space" or is a planet the sum of 3 environs and a system is a sum of planets and "spaces"?

I guess I'm wondering if there is any relationship between spaces (orbits) and planets at all, other than the fact that there is always 1 planet to 1 orbit.

from class-diagrams.

Okay so a better way to put this:

A System is composed of Planets and Spaces
A Planet is composed of Environs.
or
A System is composed of Planets
A Planet is composed of Environs and Spaces.

But Spaces cannot be an aggregate component of both Planets and Environs because you end up with infinite recursion. But I feel like you guys have a better handle on the details than I do, so I'm curious if you had to pick one of the above which makes more sense.

from class-diagrams.

I believe if the planet is removed via planetary stabilizers or w/e they are called then the orbit is no longer available. And each orbit is owned by its planet, as in going from one orbit you can only go to its planet. In order to get to a different planet you must go through that planet's orbit.

So I would vote for the 2nd option. I was trying to look ahead in the project and design the galaxy in an easy navigation tree, with environs as the bottom leafs, and going up must pass through an orbit with sibling orbits on the same level of the tree, and so on.

I guess I don't understand why Spaces cannot be a component of both Planets and Environs? I was picturing "Space" as just a place stacks can go to and leave from. It is a stand-alone structure, and Environs are Spaces with added functionality, and orbits are just Spaces.

from class-diagrams.

Oh ok, I think I see your goal now. When I say "Space" I assumed you meant Orbit, but you're actually saying an Orbit is a special type of Space.

I think maybe it might be easier to understand if we specify:

Orbit, Environ inherit Space
Planet composed of Orbit, Environ
System composed of Space, Planet

The reason I suggest that way is because Orbit really is a specialized Space (it exists as a 1:1 relationship with Planet, so Orbit should have an attached method/attribute that tells us what planet is contained in the Orbit).

I dunno maybe I'm dead wrong, I'll let you guys decide since you put in the work. If you think my way is worthy, I'll throw it together.

from class-diagrams.

That was actually an option I was leaning toward too but thought it might be nice for now to keep the # of classes to a minimum, but that sounds great to me! All fits well together, only edit I would make is that I don't think a system is composed of any "Spaces" outside of those already in the Planets if we are attaching Orbits to each Planet. Sorry the definitions weren't clear enough and caused confusion, but sounds like we are on the same page now

from class-diagrams.

@hall5714 and @crockj72

I second this...

Orbit, Environ inherit Space
Planet composed of Orbit, Environ
System composed of Space, Planet

from class-diagrams.

Checkout the new master, if you dislike anything I did PR a change or comment here. Going to close for now though.

from class-diagrams.