Class Diagram M. Seidl, et al., UML@Classroom, Introduction to Object-Oriented Modeling, Springer, 2015. Chaper 4. Soft copy (pdf) downloadable freely through UTEP library.

Class Diagram Models data, entities and static structures Most important and most widely-used diagram in UML Central model due to stability (of data), say, compared to functionalities such as use cases. Describes the structure of a system by showing the system's classes, their attributes/operations, and the relationships among the classes

Example: PC Architecture 0..2 0..2 interface IdeDevice Motherboard IdeBus interface ScsiDevice CdRom {abstract} HpCdWriter LaserController

Types of Relationships Construct Notation Association Aggregation Composition Generalization Realization Dependency

Association General binary relationships between classes Commonly represented as direct or indirect references between classes Student Course

Association Details Can express the following optional information Association name (e.g., enroll) Navigability (e.g., ->) Multiplicity (e.g., 10..*) Role names (e.g., course) 1 2 enroll Student Course 10..* course 3 4

Association Name May have an optional label consisting of a name and a direction drawn as a solid arrowhead with no tail. The direction arrow indicates the direction of association with respect to the name, i.e., the direction in which the name should be read. Use a verb or verb phrase. advise Faculty Student

Navigability An arrow may be attached to the end of path to indicate that navigation is supported in that direction. advise Faculty X Student

Multiplicity Optional multiplicity specification defining the number of objects that can participate in an instantiated relation On one or both association ends The multiplicity specifies an integer interval, e.g., l..u closed (inclusive) range of integers i singleton range 0..* entire nonnegative integer, i.e., 0, 1, 2, … advise 1 0..* Faculty Student

Role Names Optional role name on one or both association ends Use a noun or noun phrase describing the semantics of the role. advise 1 0..* Faculty Student advisor advisees

Exercise Write skeletal Java code conforming to the following model. 10..* enroll 0..* Student Course 1..3 0..* taught instructor 1 advised 1 Faculty advisor

Aggregation Special form of association representing has-a or part-whole relationship. Distinguishes the whole (aggregate class) from its parts (component class). No relationship in the lifetime of the aggregate and the components (can exist separately). Aggregate Component

Composition Stronger form of aggregation Implies exclusive ownership of the component class by the aggregate class The lifetime of the components is entirely included in the lifetime of the aggregate (a component can not exist without its aggregate). Composition Component

Example University 1..* 1..* 0..* College Department Student chair-of member-of 1 1..* Faculty

Generalization And Realization An extension relation is called specialization and generalization. An implementation relation is called realization. Superclass Superinterface Interface Subclass Subinterface Class extension of classes extension of interfaces implementation of interfaces

Example Student {abstract} Graduate {abstract} Nondegree Undergraduate Master PhD

Dependency Relationship between the entities such that the proper operation of one entity depends on the presence of the other entity, and changes in one entity would affect the other entity. The common form of dependency is the use relation among classes. <<use>> Class1 Class2

Exercise: Strength (Coupling)? Association, aggregation, composition, generalization, realization, and dependency. Weakest Strongest

Class Details The UML notation for classes is a rectangular box with as many as three compartments. Name attribute1 …… attributen operation1 … operationn The top compartment show the class name. The middle compartment contains the declarations of the attributes (fields) of the class. The bottom compartment contains the declarations of the operations (methods) of the class.

Example Attribute type Name of the class Attribute name Student - name: String = “John” {readOnly} - courses: Course [*] + register (c: Course) + isRegistered (c: Course) : Boolean Other Properties Visibility: +, -, #, ~ Default value Multiplicity Operation name Return value Parameters 20 20

Inline vs. Diagram Notation Two ways to express associations Use either one, but not both. 1 Course Instructor Course -instructor: Instructor -students: Student[10..*] -instructor 10..* -students Student

Guidelines Identify important data, entities, and domain concepts List all nouns or noun phrases Determine candidate classes Define relationships among classes Association/aggregation: has-knowledge-of, is-part- of Generalization/realization: is-a relation Define responsibilities of classes (operations) Define internal structures of classes (attributes) Refine, refine, refine …

Exercise Form a pair. Model the Battleship game by drawing a class diagram; focus on the functional core (or business logic), not UI. Assume: A board consists of n*n places (or squares), where n >= 10. A player’s feet consists of 5 ships: aircraft carrier (size 5), battleship (4), frigate (3), submarine (3), and minesweeper (2). Ships can’t overlap when placed on a board.

Sample Solution has_fleet_of Ship isSunk 5 0..1 is_placed_on s: ship size 0, s Game activePlayer changeTurn isWonBy Place hit isHit place_ships 2 1 n*n Player Board 1 pick_place_of ComputerPlayer placeShips 1 Strategy pickPlace

Exercise Any ambiguity or impreciseness in the previous class diagram? Find and list all of them. How to know that the previous diagram is a “correct” or “good” design/model? Refine it by introducing more public operations from the client view point.