Use Case & class diagrams

• A user with a clarifying name.
• A named box that represents the system.
• Actual verb noun use cases in the box.

• X includes Y ==   X --> Y 
• Use case X must include use case Y to be complete.

• X extends Y ==   X --> Y 
• Use case X may include use case Y to be complete.

• It is a class diagram where the classes are "empty".
• The diagram does not focus in implementation details but on the relation between classes.

A "owns" B = Composition : B has no meaning or purpose in the system without A

A "uses" B = Aggregation : B exists independently (conceptually) from A

Example 1:A Company is an aggregation of People. A Company is a composition of Accounts. When a Company ceases to do business its Accounts cease to exist but its People continue to exist.

Example 2: (very simplified)A Text Editor owns a Buffer (composition). A Text Editor uses a File (aggregation). When the Text Editor is closed, the Buffer is destroyed but the File itself is not destroyed.

Aggregation(empty rectangle): If a dog breed goes extinct, dogs don't go extinct.

Composition(filled rectangle): If dogs go extinct, the dog breed also goes extinct.

The ability of one class (child class) to inherit the identical functionality of another class (super class), and then add new functionality of its own. (In a very non-technical sense, imagine that I inherited my mother's general musical abilities, but in my family I'm the only one who plays electric guitar.

• Simply put: a multiplicity is made up of a lower and an upper cardinality.
• A cardinality is how many elements are in a set. Thus, a multiplicity tells you the minimum and maximum allowed members of the set.

"Multiplicity" "class-A" "relation" "Multiplicity" "class-B"

All good software design will go for high cohesion and low coupling.

Cohesion refers to what the class (or module) will do. Low cohesion would mean that the class does a great variety of actions and is not focused on what it should do. High cohesion would then mean that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class.

As for coupling, it refers to how related are two classes / modules and how dependent they are on each other. Being low coupling would mean that changing something major in one class should not affect the other. High coupling would make your code difficult to make changes as well as to maintain it, as classes are coupled closely together, making a change could mean an entire system revamp.

Identify and model classes—Which classes do we need to make the system work?

• What methods will the class use to serve its purpose? Both send and receive.
• What attribute(objects) are needed for the functions to work?

Used to create Use case realizations for example. 

• write down the events in pseudo.
• Then what classes etc will be used to complete the use case?
• Are all classes affected by the use case event listed in the sequence diagram?

• Used to model diffrent stastes an object for example can be in. 
• Whare does it start? where does it end? what happens inbetween / can happen?
• Changes of made to the object can be descrived by "Evt"name" /what funct is triggerd() by that. so evt NextSong button pressed / nextsongin list()

start & stop points are added at every state where they can be connected, therefor they can be repeated

• User interface layer
• canvas class:upd display() etc

• Application interface layer
• handle User input usch as button press() etc

• domain layer
• Classes that make the actuall system run

• library layer
• Classes like wifi bluetooth airplay etc