pull from main

docs/lectures/dms/01_java_collections.md

@@ -0,0 +1,135 @@
+# Java Collections
+
+Week 3 (Oct 5th)
+
+**Part 1**
+
+In java a *collection* is an object that represents a group of objects.
+The collections API is a unified framework for representing and manipulating collections independently of their implementation.
+
+An *API* (application programming interface) is an interface protocol between a client and a server, intended to simplify the client side software.
+
+A *library* contains re-usable chunks of code.
+
+**Java Collections framework**
+- We have container objects that contain objects
+- All containers are either "collections" or "maps"
+- All containers provide a common set of method signatures, in addition of their unique set of method signatures
+
+*Collection* - Something that holds a dynamic collection of objects
+*Map* - Defines mapping between keys and objects (two collections)
+*Iterable* - Collections are able to return an iterator objects that can scan over the contents of a collection one object at a time
+
+NOTE: Vector is a legacy structure in Java replaced with *ArrayList*
+      Stack is now *ArrayDeque*
+
+`LinkedList(Collection<? extends E> c)` - means some type that either is E or a subtype of E. The `?` is a wildcard.
+
+```java
+public static void main(String[] args) {
+     LinkedList list = new LinkedList();
+     list.add("string");
+     String s = (String)list.getFirst();
+     System.out.println(s);
+}
+```
+
+This is bad coding practice, the collection constructor are not able to specify the type of objects the collection is intended to contain. A `ClassCastException` will be thrown if we attempt to cast the wrong type.
+
+```java
+public static void main(String[] args) {
+     LinkedList<String> list = new LinkedList<>();
+     list.add("string");
+     String s = list.getFirst();
+     System.out.println(s);
+}
+```
+
+This is a type safe collection using generics.
+- Classes support generics by allowing a type variable to be included in their declaration.
+- The `<>` show the same type as stated (in this case string)
+- You cannot type a collection with a primitive data type eg int
+
+**HashMap Class**
+- A HashMap is a hash table based implementation of the map interface. This implementation provides all if the optional map operations, and permits null values and the null key.
+
+```java
+public static void main(String[] args) {
+     HashMap<String, Integer> userData = new HashMap<>();
+	 userData.put("Emma", 30);
+	 userData.put("John", null);
+	 userData.put("Millie", 17);
+
+	 Set<String> keys = userData.keySet();
+
+	 for (String key:keys){
+	 	System.out.println(key + "=" userData.get(key));
+	 }
+}
+```
+
+```
+Emma = 30
+John = null
+Millie = 17
+```
+
+**Part 2**
+
+__Relationships between objects__
+
+*Aggregation* - The object exists outside the other. It is created outside so it is passed as an argument.
+An animal object *is part of* a compound object (semantically) but the animal object can be shared and if the  compound object is deleted, the animal object isn't deleted.
+
+```java
+public class Compound {
+	private Animal dog;
+
+	public void setAnimal(Animal dog){
+		this.dog = dog;
+	}
+}
+```
+
+![Image](assets/1.png)
+
+*Composition* - The object only exists if the parent object exists, if the parent object is deleted then so is the child object.
+The zoo object owns the compound object. If the zoo object is deleted then the compound object is also deleted.
+
+```java
+public class Zoo {
+	private Compound dogArea = new Compound();
+}
+```
+
+![Image](assets/2.png)
+
+**Inheritance**
+A way of forming new classes based on existing classes. Has a "is-a" relationship.
+
+*Polymorphism* - A concept in object oriented programming. Method overloading and method overriding are two types of polymorphism.
+- *Method Overloading* - Methods with the same name co-exist in the same class but they must have different method signatures. Resolved during compile time (static binding).
+- *Method Overriding* - Methods with the same name is declared in parent and child class. Resolved during runtime (dynamic binding).
+
+```java
+public class Child extends Parent {
+	public Child(String name){
+		super(name);
+	}
+	
+	@Override
+	Public void eat() {
+		chew();
+	}
+}
+```
+
+The super keyword called the parent class' constructor.
+
+![Image](assets/3.png)
+
+**What is the difference between an abstract class and an interface**
+- Java abstract class can have instance methods that implement a default behaviour. May contain non-final variables.
+- Java interfaces have methods that are implicitly abstract and cannot have implementations. Variables are declared final by default.
+
+Interfaces are less restrictive when it comes to inheritance, interfaces can have many levels of inheritance where as a class can only have one level.

docs/lectures/dms/02_uml.md

@@ -0,0 +1,92 @@
+# Unified Modelling Language
+
+12/10/20
+
+**UML**: A specification defining a graphical language for visualising, specifying, constructing and documenting the artefacts of distributed object systems.
+
+Latest version: **2.6**
+
+**Benefits of UML**
+
+- Enhances communication and ensures the right communication 
+- Captures the logical software architecture independent of the implementation language.
+- Helps to manage the complexity
+- Enables reuse of design
+
+<img src="assets/4.png" alt="img" style="zoom:80%;" />
+
+
+## Object Orientated Analysis
+
+**Use case diagrams**
+
+- Describe a set of actions that some system should or can perform in collaboration with one or more external users of the system.
+- No attempt to represent an order or a number of executions.
+
+**Use case diagram components**
+
+`Actors` - Entities that interface with the system. Can be people or other systems.
+
+`Use case` - Based on user stories and represent what the actor wants your system to do for them. In the use case diagram only the use case name is represented.
+
+`Subject` - Classifier representing a business, software system, physical system or device under analysis design, or consideration.
+
+`Relationships` 
+
+> Relationships between use case and actor
+>
+> 1. Association indicates which actor indicates which use case
+>
+> Relationship between two use cases
+>
+> 1. Specifying common functionality and simplifying use case flows
+> 2. Using <<include>>  or <<extend>>
+
+**`<<include>>`**- multiple use cases share a piece of same functionality which is placed in a separate use case.
+
+**`<<extend>>`** - Used when activities might be performed as part of another activity but are not mandatory for a use case to run successfully.
+
+
+**Use case diagram of a fleet logistics management company**
+
+![image](assets/5.png)
+
+
+**Base Path** - The optimistic path (best case scenario)
+
+**Alternative Path** - Every other possible way the system can be used/abused. Includes perfectly normal alternate use, but also errors and failures.
+
+
+Use Case: `Borrow copy of book`
+
+> **Purpose**: The book borrower (BB) borrows a book from the library using the Library Booking System (LBS)
+>
+> **Pre-conditions**: 
+>
+> 1. The book must exist
+> 2. The book must be available
+>
+> **Base Path**:
+>
+> 1. LBS requests membership card
+> 2. BB provides membership card
+> 3. BB is logged in by LBS 
+> 4. LBS checks permissions / debts 
+> 5. LBS asks for presenting a book 
+> 6. BB presents a book 
+> 7. LBS scans RFID tag inside book 
+> 8. LBS updates records accordingly 
+> 9. LBS disables anti-theft device 
+> 10. BB is logged out by LBS 
+> 11. LBS confirms that process has been completed successfully
+>
+> **Alternative Path**
+>
+> 1. BB's card has expired: Step 3a: LBS must provide a message that card has expired; LBS must exit the use case
+>
+> **Post conditions for base path**
+>
+> **Base path** - BB has successfully borrowed the book & system is up to date.
+>
+> **Alternate Path 1** - BB was NOT able to borrow the book & system is up to date.
+

mkdocs.yml

@@ -62,10 +62,10 @@ nav:
   - Home: index.md
   - Books:
     - Designing Data-Intensive Applications:
-      - Preface: books/designing_data_intensive_applications/preface/index.md
+        - Preface: books/designing_data_intensive_applications/preface/index.md
-      - Part 1. Foundations of Data Systems:
+        - Part 1. Foundations of Data Systems:
-        - Chapter 1. Reliable, Scalable and Maintainable Applications: books/designing_data_intensive_applications/part1/chapter1.md
+          - Chapter 1. Reliable, Scalable and Maintainable Applications: books/designing_data_intensive_applications/part1/chapter1.md
-        - Chapter 2. Data Models and Query Languages: books/designing_data_intensive_applications/part1/chapter2.md
+          - Chapter 2. Data Models and Query Languages: books/designing_data_intensive_applications/part1/chapter2.md
     - API Design Patterns:
       - Part 1. Introduction:
         - Chapter 1. Introduction to APIs: books/api_design_patterns/part1/chapter1.md
@@ -73,4 +73,7 @@ nav:
       - Part 2. Design Principles:
         - Chapter 3. Naming: books/api_design_patterns/part2/chapter3.md
         - Chapter 4. Resource Scope and Hierarchy: books/api_design_patterns/part2/chapter4.md
-
+  - Lecture Notes:
+    - Developing Maintainable Software:
+      - Java Collections: lectures/dms/01_java_collections.md
+      - UML Diagrams: lectures/dms/02_uml.md