W2561 UML Class Diagrams

From Coder Merlin
Revision as of 13:21, 20 June 2019 by Chukwuemeka-tinashe (talk | contribs) (Merlin moved page Project-2561 to W2561 UML Class Diagrams: Improved navigation)
Within these castle walls be forged Mavens of Computer Science ...
— Merlin, The Coder
Joy Oil Gas Station Blueprints
Autograph score of the Prague Symphony by Mozart

Prerequisites[edit]

Research[edit]

Examples[edit]

Dependency[edit]

Alpha uses Bravo as a parameter to Alpha.f(). A transient relationship exists.

class Alpha {
    func f(bravo:Bravo) {
        bravo.g()
    }
}

Aggregation[edit]

Alpha has-a Bravo but Bravo's existence is independent of Alpha.

class Alpha {
    var bravo : Bravo?

    init(bravo:Bravo) {
        self.bravo = bravo
    }
}

Composition[edit]

Alpha has-a Bravo and owns Bravo; Bravo's existence is dependent on Alpha.

class Alpha {
    let bravo : Bravo

    init() {
        bravo = Bravo()
    }
}


Key Concepts[edit]

UML Class Relation Arrows
  • General
    • has-a/part-of generally means that one class has (either through ownership or aggregation) another object
    • is-a generally means that one class is a subtype of another
    • can-do-a generally means that one class can perform some function as described by an interface
  • Class Diagrams provide a means for communicating the general, static, conceptual model of an application
  • Classes are represented by a box with with three compartments
    • The top compartment contains the name of the class, capitalized and centered
    • The middle compartment contains the attributes (properties) of the class, left-aligned in camel case
    • The bottom compartment contains the operations (methods) of the class, left-aligned in camel case
      • Abstract operations are indicated by using italics for the operation name
  • An abstract class is indicated by using italics for the class name
  • Visibility notations may be placed in front of the attributes and operations
    • + indicates public access
    • - indicates private access
    • # indicates protected access
  • Scope notations may be used to specify the scope of attributes and operations
    • An underline indicates classifier (static) scope
    • The lack of an underline indicates instance scope
  • A relationship describes logical connections between entities
    • Class-Level relationships
      • Inheritance indicates that one of the classes is a specialized form (subclass) of the other (superclass). This is also known as an is a relationship, e.g. "a dog is a mammal". This is indicated on a diagram by drawing a line from the subclass to the superclass with a hollow triangle on the superclass end.
      • Realization indicates that one of the classes (the client) realizes (implements) the behavior specified by the other class (the supplier or interface). This is indicated on the diagram by drawing a dashed line from the client to the interface with a hollow triangle on the interface end. The interface itself has an <<interface>> tag above the "class" name.
    • Instance-Level relationships
      • A dependency represents a semantic relationship between two elements. It is represented as a dashed line with an arrow head pointing in the direction of the dependency. Note that actual interaction may be transient and limited to a class reference as an argument to a method.
      • An association represents a tighter link than a dependency when the relationship generally exists throughout the lifetime of the class as a reference to another class.
        • A unidirectional association is represented as a solid line with an arrow head pointing in the direction of the association.
        • A bidirectional association is represented as a solid line between the classes.
        • Aggregation is a form of weak association with a "part-of" relationship, where the contained classes do not have a lifecycle dependency on the container yet are "used" by it. It is represented with a hollow diamond on the containing class with a line drawn to the contained class.
        • Composition is a form of strong association where the contained class is "owned" by the container. It is represented as a filled diamond on the containing class with a line drawn to the contained class.

Exercises[edit]

  1. Construct a UML diagram (either on paper or electronic tool such as www.draw.io). Be sure to include all important properties and methods and ensure that relationships between classes are represented correctly.