UML interpretation

• inheritance and hierarchy helps avoid repetition
• superclass provides attributes and operations in common to all subclasses, can call for mandatory implementation of methods if abstract
• Inheritance: is-a relationship, superclasses and subclasses, eg. pink ball is a enemy.

  
• Inheritance (specialisation and generalisation) is represented by an unfilled arrow pointing up to the superclass
• concrete classes are the opposite of abstract classes. Abstract classes should never be children of concrete classes
• can create abstract variables. substitution principle says the values can be references to concrete classes (subclass values)
• UML abstract class = italic name
• Interface: set of public abstract method declarations that enforce implementation. cannot have attributes
• classes can implement multiple interfaces
• UML interface = <<interface>> above interface name

  
• UML interface implementation = unfilled, DASHED arrow pointing to the interface
• in java: extends = inheritance, subclass cannot access private atts/methods of the superclass
• Collaborations: represent a client object request to a server object. client collaborates with server to address server responsibility and help fulfil client responsibility
• collaboration represents flow of dependency and information in a system, defining a communication pattern and indentifying subsystems
• has-knowledge-of relationship: class A collaborates with B (asks for a service), but is independent in existence
• is-part-of relationship: one class is a composite, the other a component. Composites maintain information about/from the components
• Association: has-knowledge-of relationship, usually a link of tracking between two objects (eg. an attribute = (something from) another object).

  
• association is represented by a line with the 'association' (eg. owns) written above it, and a small arrowhead pointing to the direction of flow
• there can be multiple different associations between a given 2 classes, and a class can be related to itself

  
• multiplicities are basically cardinality for associations in the form (min)..(max) (with * meaning many). lack of a multiplicity leaves the decision open to the programmer

  
• having a min multiplicity on each side disallows any of each to not be related to the other

  
• associations can show which instances can get to whoch other objects. - arrow end pointing to class = navigable to that class, cross at end of line = not navigable to that class

  
• Aggregation: is-part-of relationship. can exist independently but the composite class is still made up of them (eg. modules in a course)
• Composition: is-part-of where children cannot exist independently (eg. tang or middle of a blade)
• Aggregation = an unfilled diamond, used to model assemblies of independent objects

  
• Composition = filled diamond, reads as 'owns a'