# Week 9

## Class Diagrams: Intermediate-Level
- A class diagram can also show different types of relationships between classes: inheritance, compositions, aggregations, dependencies.

### Modeling inheritance
- You can use a **triangle** and a **solid line** to indicate class inheritance.

### Modeling composition
- A composition is an association that **represents a strong whole-part relationship**. When the *whole* is destroyed, *parts* are destroyed too.
- Composition also implies that there **cannot be cyclical links**.
- UML uses a **solid diamond symbol** to denote composition.

#### Implementing composition
- Composition is implemented using a **normal variable**.
- If correctly implemented, the ‘part’ object will be deleted when the ‘whole’ object is deleted. Ideally, the ‘part’ object may not even be visible to clients of the ‘whole’ object.

> In this code, the Email has a composition type relationship with the Subject class, in the sense that the subject is part of the email.

class Email {
    private Subject subject;
  ...
}

### Modeling aggregation
- Aggregation represents a **container-contained relationship**. It is a weaker relationship than composition.
- UML uses a **hollow diamond** is used to indicate an aggregation.
- Which one of these is **recommended not to use** in UML diagrams because it adds more confusion than clarity?
- [ ] a. Composition symbol
- [x] b. Aggregation symbol

#### Implementing aggregation
- Implementation is similar to that of composition except the containee object can exist even after the container object is deleted.

> In the code below, there is an aggregation association between the Team class and the Person in that a Team contains Person a object who is the leader of the team.

class Team {
    Person leader;
    ...
    void setLeader(Person p) {
        leader = p;
    }
}

### Modeling dependencies
- A dependency is a need for one class to depend on another **without having a direct association** with it. One cause of dependencies is interactions between objects that do not have a long-term link between them.
- UML uses a **dashed arrow** to show dependencies.

#### Implementing dependencies
> In the code below, Foo has a dependency on Bar but it is not an association because it is only a transient interaction and there is no long term relationship between a Foo object and a Bar object. i.e. the Foo object does not keep the Bar object it receives as a parameter.

class Foo{
    
    int calculate(Bar bar){
        return bar.getValue();
    }
}

class Bar{
    int value;
    
    int getValue(){
        return value;
    }
}

### Modeling enumerations

### Modeling abstract classes
- You can use italics or {abstract} (preferred) keyword to denote abstract classes/methods.

### Modeling interfaces
- An interface is shown similar to a class with an additional keyword **<<interface>>**. When a class implements an interface, it is shown similar to class inheritance except a **dashed line** is used instead of a solid line.

## Logging
- Logging is the deliberate recording of certain information during a **program execution** for future reference.

First, import the relevant Java package:

import java.util.logging.*;

Next, create a Logger:

private static Logger logger = Logger.getLogger("Foo");

Now, you can use the Logger object to log information. Note the use of logging level for each message. When running the code, the logging level can be set to WARNING so that log messages specified as INFO level (which is a lower level than WARNING) will not be written to the log file at all.

// log a message at INFO level
logger.log(Level.INFO, "going to start processing");
//...
processInput();
if(error){
    //log a message at WARNING level
    logger.log(Level.WARNING, "processing error", ex);
}
//...
logger.log(Level.INFO, "end of processing");

## Assertions
- **Assertions are used to define assumptions about the program state so that the runtime can verify them.** An assertion failure indicates a possible bug in the code because the code has resulted in a program state that violates an assumption about how the code should behave.
- **If the runtime detects an assertion failure, it typically take some drastic action** such as terminating the execution with an error message.
- Use the **`assert` keyword to define assertions**.

> This assertion will fail with the message x should be 0 if x is not 0 at this point.

x = getX();
assert x == 0 : "x should be 0";
...

- Assertions can be disabled without modifying the code.
ex. `java -enableassertions HelloWorld` (or `java -ea HelloWorld`) will run `HelloWorld` with assertions enabled while `java -disableassertions HelloWorld` will run it without verifying assertions.
- **Java disables assertions by default.**
- Assertions are suitable for **verifying assumptions about Internal Invariants, Control-Flow Invariants, Preconditions, Postconditions, and Class Invariants**.
- **Exceptions and assertions are two complementary ways of handling errors** in software but they serve different purposes. Therefore, **both assertions and exceptions should be used in code**.
- The raising of an **exception** indicates an **unusual condition** created by the user (e.g. user inputs an unacceptable input) or the environment (e.g., a file needed for the program is missing).
- An **assertion failure** indicates the **programmer made a mistake** in the code (e.g., a null value is returned from a method that is not supposed to return null under any circumstances).

## Design Principles
### Abstraction
- The guiding principle of abstraction is that **only details that are relevant to the current perspective or the task at hand needs to be considered.**
- ==Data abstraction==: abstracting away the lower level data items and thinking in terms of bigger entities
- ==Control abstraction==: abstracting away details of the actual control flow to focus on tasks at a higher level
> print(“Hello”) is an abstraction of the actual output mechanism within the computer.

### Coupling
- **Coupling is a measure of the degree of dependence between components, classes, methods, etc**. ==**Low coupling**== indicates that a component is **less dependent** on other components. ==**High coupling**== (aka tight coupling or strong coupling) is **discouraged** due to the following disadvantages:
- **Maintenance is harder** because a change in one module could cause changes in other modules coupled to it (i.e. a ripple effect).
- **Integration is harder** because multiple components coupled with each other have to be integrated at the same time.
- **Testing and reuse of the module is harder** due to its dependence on other modules.

> Discuss the coupling levels of alternative designs x and y.
-> Overall coupling levels in x and y seem to be similar (neither has more dependencies than the other). (Note that the number of dependency links is not a definitive measure of the level of coupling. Some links may be stronger than the others.). However, in x, A is highly-coupled to the rest of the system while B, C, D, and E are standalone (do not depend on anything else). In y, no component is as highly-coupled as A of x. However, only D and E are standalone.

> Explain the link (if any) between regressions and coupling.
-> When the system is highly-coupled, the risk of regressions is higher too e.g. when component A is modified, all components ‘coupled’ to component A risk ‘unintended behavioral changes’.

> Discuss the relationship between coupling and testability.
-> Coupling decreases testability because if the SUT is coupled to many other components it becomes difficult to test the SUI in isolation of its dependencies.

- **X is coupled to Y if a change to Y can ==potentially== require a change in X.**

### Cohesion
- **Cohesion is a measure of how strongly-related and focused the various responsibilities of a component are.** A highly-cohesive component keeps related functionalities together while keeping out all other unrelated things.
- **Higher cohesion is better**. Disadvantages of low cohesion (aka weak cohesion):
- **Lowers the understandability of modules** as it is difficult to express module functionalities at a higher level.
- **Lowers maintainability** because a module can be modified due to unrelated causes (reason: the module contains code unrelated to each other) or many many modules may need to be modified to achieve a small change in behavior (reason: because the code related to that change is not localized to a single module).
- **Lowers reusability of modules** because they do not represent logical units of functionality.

### Single Responsibility Principle
- Single Responsibility Principle (SRP): **A class should have one, and only one, reason to change.**

### Separation of Concerns Principle
- Separation of Concerns Principle (SoC): **To achieve better modularity, separate the code into distinct sections, such that each section addresses a separate concern.**
- This principle should lead to **higher cohesion and lower coupling.**

## Testing: Intermediate Techniques
- **Testability is an indication of how easy it is to test an SUT.** As testability depends a lot on the design and implementation. You should try to increase the testability when you design and implement a software. **The higher the testability, the easier it is to achieve a better quality software.**