Class Diagrams - 1

Naming Classes

Classes should be named with:

We can use two different methods to derive classes:

Data Driven Design (DDD) - We identify all the data of the system and divide it into classes. We then assign particular responsibilities (methods) to these classes.]
Responsibility Driven Design (RDD) - We identify all the responsibilities of the system and divide them into classes. We then find the data each class requires.

If some object of class $A$ has to know about some object of class $B$ then they have an association.

We can also note multiplicity on the association:

classDiagram
direction LR
Doctor "1" --> "1..*" Patient:has allocated

Attributes - Describe the data contained in an object of the class and their type.
Operations - Define the way in which objects may interact.

classDiagram
class Patient {
-String name 
-Date dateOfBirth 
+addAppointment()
+getDateOfBirth() Date
+addPrescription()
}

You can overwrite the an inherited method using dynamic binding:

classDiagram
direction TB
Vehicle <|-- Car
Vehicle <|-- Boat
Vehicle: startEngine()
Car: +startEngine()
Boat: +startEngine()

All attributes and methods from the top of the inheritance are passed though to the children:

classDiagram
Animal <|-- Cat
Animal <|-- Dog
class Animal {
Integer Age
getAge() Integer
}
Cat: meow()
Dog: bark()

The following are examples of CRC (classes, responsibilities, collaborations) cards:

LibraryMember
Responsibilities	Collaborators
Maintain data about copies currently borrowed. Meet requests to borrow and return copies.	`Copy`

Copy
Responsibilities	Collaborators
Maintain data about a particular copy of a book. Inform corresponding `Book` when borrowed and returned.	`Book`

Book
Responsibilities	Collaborators
Maintain data about one book. Know whether there are borrow-able copies.