More UML

• I am using "Learning UML 2.0" from O'Reilly.
  • Chapter 5, Modeling a System's Logical Structure
• Class relationships are depicted in UML diagrams.
  • 
• A dependency indicates that two classes work together briefly
  • Your classes use a string class item.
  • In our case, a UI element will depend on a RollT or DisasterT to be able to print it.
  • In a note, the author states "The dependency relationship is often used when you have a class that is providing a set of general purpose functions ..."
  • Drawn with a dashed line and an arrow.
  • 
• An Association
  • One class contains a reference to another.
  • The key term is "works with"
  • I believe in our game, a GameT will have an association with a DieT.
    • At various stages the game will declare a DieT

      void GameT::LeaderRoll(PlayerT player) {
      	DieT LeaderDie(LEADER_ROLL_SIDES);
      	RollT roll = RollT::LEADER;
          
              int dieCont = 1,
      	    bonus = 0;
      
              /* code to get ready to do Leader roll */
      
              DoDieRoll(roll, LeaderDie, dieCount, bonus, player);
      
              return
      }
      

    • Note that a die is used, but not a member of the class.
  • A solid line with an arrow is used for an association
  • 
  • Note we can label the portions of the association in umlet

  • lt=<-
    m1=0..n
    m2=1
    Rolls
    

  • 
• An Aggregation
  • This relationship is the next level.
  • The author states "a class ownes but may share objects of another class."
  • Examples are where multiple entities have an instance of an object.
  • In our case, A player and a wonder or an advance.
    • If a player is destroyed, the wonder or advance will still continue to exist.
    • This is a has-a relationship.
  • An empty diamond pointing to the owner.

  • lt=<<<<-
    m1=0-1
    m2=*
    ownes >
    	

  • 
• A composition
  • Indicates that one class is built from another class.
  • In our case a player is composed of (in part) a wonderElement
  • One can not exist without the other.
  • Both are created and destroyed at the same time.
  • 
• The main difference here is the strength of the relationship.
  • The code for all four are about the same.
  • In some cases it might be a list with 0 or more elements.
  • In other cases it will be an instance of the other class.
• Generalization or Inheritance (In our text book, Chapter 5 p 114)
  • is-a relationship.
  • We don't have any of these yet, but in the future I can see us introducing a AssetT
    • Wonders, Advances, even Leaders are assets to a civilization.
    • A city might be an asset as well.
    • They all have a name.
    • They all can provide a modification to a roll or extra victory points.
  • We think in terms of a parent or base class (an AssetT)
  • And a derived or specialized class (WonderT, AdvanceT, LeaderT, CityT)
  • Derived classes have the ability to
    • Add functionality or properties to the base class.
    • Override or Replace functionality or properties to the base class.
  • Let's develop this incrementally
    • AssetT
    • Then a DieModifyAssetT
    • Then a DisasterMitigationAssetT
    •