The Unified Modeling Language (UML) Class Diagrams

1. The Unified Modeling Language (UML)Class Diagrams

2. 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

3. 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

4. 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

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

6. A Class • 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 Class/Object Name Attributes Methods/Operations

7. Visibility of Attributes and Methods

8. Associations

9. 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)

10. 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

11. 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

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

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

14. 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

15. 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

16. Source: bigelow.ch

17. 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