The Unified Modeling Language (UML) Class Diagrams

Unified Modeling Language A standardized modeling language for the conceptualization and design of software systems Two types of diagrams: structure diagram and behavior diagram There are a lot of diagram types in the UML (14 types!) but we will focus only on a few in this class

Common Structure Diagrams Class Diagram – Illustrates classes, with attributes and methods, along with their relationships – We will focus primarily on class diagrams, since they are by far the most commonly used Component Diagram – Illustrates how components (each with an API or similar connecting interface) interfaces with other components Object Diagram – Illustrates the objects instantiated in a system at a single point in time Package Diagram – Illustrates the packages in a system and their dependencies

Common Behavior Diagrams Activity Diagram – A “flow chart” of sorts Interaction Diagram – The message sequence chart is one type of interaction diagram Use Case Diagram – Represents dependencies among use cases State Machine Diagram – Displays states and transitions

UML Diagrams are related Each diagram is a different view of a system These classes belong to those packages.

A Class Class/Object Name Attributes Methods/Operations A class name should be descriptive (Italic if abstract) The attributes of a class defines its properties, what data the class stores The methods/operations of a class specify what the class does

Visibility of Attributes and Methods

Associations

Specific Associations: Aggregate Aggregations – “has a” relationships – A class is a container of other classes – Does not imply ownership, (ie. when the “parent” gets destroyed, the aggregates do not) – Ex: A magazine has articles, but if the magazine goes out of business, the articles don’t necessarily disappear (they may live on as part of another publication)

Specific Associations: Composite Composition – combining simple objects into a more complex whole – Can have multiple objects composed into one – Implies an “owns a” relationship – If the parent is destroyed, all its composites are typically destroyed – Ex: If we delete the article we no longer care about Facebook comments on the article

Difference between Composition and Aggregation Composition: – Composed of multiple parts – Parts have no independent existence – The structured whole makes the object Aggregation: – Does not imply ownership – Parts have independent existence – May be called a composition if the distinction is not important

Generalization/Specialization Generalization: “a parent” Specialization: “a child”, inherits from a general class

Realization (Implementation) Relationship where one class (the client) implements another (the supplier) Represented with a dashed line from the implemented class to the implementation

Dependencies A “using” relationship specifying that a change in the specification of one thing may affect another thing that uses it Common when the client class: – Uses a supplier class that has global scope – Uses a supplier class as a parameter – Uses a supplier class as a local variable – Sends a message to the supplier

UML Examples This level of detail is usually reserved for the Design and Implementation phases – Deliverable 3: design – Deliverable 4: implementation You will not need to add all of these details in your Deliverables 2 or 3

Source: bigelow.ch

Combinations of UML Diagrams A class might have behavior attached to it Behavior specified usually through a UML activity diagram or a UML state diagram