Introduction
This part of the course focus on the following user stories:

As a software designer I want to understand how users plan on interacting with the system so that I can design the right API endpoints.
As a software designer I want to understand how domain concepts interact so that I can select the best way to implement these interactions.
As a software designer I want to model both the dynamic behaviour as well as the static structure of the application so that I can communicate both to the developers.
As a software implementer I want to know which methods and attributes each class contains so that I can implement them.

The following concepts are introduced:

Class
Instance
Object
Object state
Class Diagram
Domain Model (Also: Conceptual Model)
System Event
Black Box
Interaction Diagrams
- Sequence Diagrams
- Collaboration Diagrams (Also: Communication Diagram)
- System Sequence Diagram
Operation Contracts (Also: Design Contracts)
Class Diagrams
- Associations
- Aggregation
- Composition
- Class Roles
- Multiplicity
Dynamic Behaviour
Static Structure

You are done when

You understand how to use your UML use cases to identify system events, that will trigger a series of interactions inside the system.
You understand how to start identifying candidate entities for this internal structure through the use of a Domain Model.
You have an understanding of how the dynamic behaviour of the system is used to identify the static structure
You have an understanding of how you may use your previous analysis, in terms of Use Cases and Domain Model to initiate your design of the dynamic behaviour and static structure.

From Domain Concepts to Classes

What is the difference between a class and a concept? Should all concepts in your domain become classes? Vice versa, should all classes be concepts?

UML has managed (Not sure if it is by intention) to blur the border between what is a concept and what is a class, especially since we use the same diagram notation for domain models as we do for class models (or class diagrams, as they are mostly called). I'll try to explain this a bit for you.

A concept is something which you observe in the real world (that is, the problem domain). You may have an idea of what a concept can do, what attributes a concept may have, the relations a concept may have with other concepts, and the types of these relations. Your domain model does not have to be complete: at any moment in time, it represents your best understanding of how the problem domain works.

For example, if I'm modelling a truck company, I may have concepts such as Truck, Driver, Destination, and Cargo (these are my concepts). I may note that Driver drives a Truck, a Truck has a Destination, and a Truck is loaded with Cargo (relations between concepts). Further, a Truck may have a LastServicedDate and a maxSpeed (attributes).

In contrast, a class, is a detailed blueprint of what you intend to build (if we stick to the design mindset. Obviously, if you are already programming then the class is something you have already built and is using as a blueprint to instantiate objects). As a detailed blueprint, you want to know exactly which methods to implement, and exactly which attributes and attribute types you should include. You also want to know exactly how this class relates to other classes.

Your class diagram should be a complete description of everything you have already built, or is intending to build in the current iteration. Let's say that right now, the customer is only interested in managing the Trucks. They do not care about the drivers or the cargo yet. So you only need to implement the Truck class.

Only? Not really. If you are going to maintain a fleet of Trucks, you are going to have more than one object of the type Truck in your system (one object each for your real world trucks). This means that you need some way to manage this collection of objects, e.g. with a TruckManager. Then, you need a starting point for your system, say a TruckSystem class, that contains your main() method.

Thus, you have concepts that never make it into classes, because they are not in focus right now (or you decide to use a builtin data type for them). Moreover, you have classes with no corresponding concept (such as the TruckManager and TruckSystem classes).

For those concepts that are made into classes, however, the underlying philosophy with object oriented design is to make sure that the class names, attributes and methods are as close as possible to what you find in the problem domain.

And that is why we use the same UML notation for domain modelling and for class diagrams. It makes it easier to extract concepts from the domain model and turn them into classes, and it drives home the point that you should try to make them look as similar as possible.

Concepts and Objects

Looking at the real world, you are going to see a lot of instances of concepts. You may, for example, see the Trucks "Big Red", "Tow Mater", "Thomas", and "Bumblebee". You would not model each of these as separate concepts, but instead look for their archetype Truck. In the same way, once you start implementing your system, you do not create a separate class for each of them; you implement the concept-corresponding class Truck, and then you create objects that represent the real world trucks:

var trucks = [new Truck("Big Red"), new Truck("Tow Mater"), new Truck("Thomas"), new Truck("Bumblebee")];

Getting the Minimum Viable Product

Just copying all you know about a concept into a corresponding class usually means that you will end up implementing stuff which is not used right now. So in order to figure out the minimal set of attributes, methods, and relations (and classes, for that matter) that is needed right now, you need to step back from the static structure and look at the dynamic behaviour of your system.

This is one of the main takeway of this module. What I want you to realise is that modelling the dynamic behaviour of your system is the key to understanding the static structure. This is the best way to keep your system lean.

TL;DR: Use the dynamic behaviour of your system to extract the least possible amount of static structure, to keep your design relevant and lean.

Click "Next" to find out how.