doc: update lecture 11 slides

lectures/revealjs/11-lecture-solid-uml.adoc

+= Object oriented design principles 
+:customcss: slides.css
+:icons: font
+:includedir: includes/
+:LECTURE_TOPIC: OOP SOLID + UML 
+:LECTURE_NO: 11th Lecture
+
+include::{includedir}header.adoc[]
+
+[.smaller-80][.center-paragraph]
+IT1901 Fall 2022 - {LECTURE_NO}
+
+
+
+[.smaller-30]
+Partially based on slides from Torgeir Dingsøyr and Hallvard Trætteberg
+
+
+== Overview
+- OOD -  SOLID, DRY
+- UML Diagrams
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Object Oriented Design
+
+
+== Object Oriented Design
+
+“An object-oriented system is made up of interacting objects that 
+maintain their own local state and provide operations on that state. 
+The representation of the state is private and cannot be accessed directly 
+from outside the object. Object-oriented design processes involve 
+designing object classes and the relationships between these classes.” 
+(Sommerville: p 198)
+
+
+== Object Oriented Principles
+
+- Encapsulation
+- Abstraction
+- Inheritance
+- Polymorphism
+
+
+== Common issues OOD
+
+- External dependencies:
+** New requirements can produce changes in many places
+
+- Internal dependencies:
+** changes in a part of the code affect other parts
+** difficult to re-use code
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== SOLID principles
+
+== SOLID principles 
+
+- **S**ingle responsibility principle
+- **O**pen–closed principle
+- **L**iskov substitution principle
+- **I**nterface segregation principle
+- **D**ependency inversion principle
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Single responsibility principle
+
+
+== Single responsibility principle
+
+- A class should only have a single responsibility
+- A class should have one, and only one reason to change
+- Examples:
+** simpleexample2: JSON-serialization
+*** Latlong serializer
+*** Latlong deserializer
+
+
+== Single responsibility principle
+
+Applying this principle has as effects:
+
+- Smaller sized classes
+- Classes that are easier to:
+** understand
+** test
+** maintain
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Open–closed principle
+
+== Open–closed principle
+
+- Software entities should be open for extension, but closed for modification.
+- Example: JavaFX classes
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Liskov substitution principle
+
+== Liskov substitution principle
+
+- Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
+
+
+== Liskov substitution principle (2)
+
+image::../images/lecture11/rectangle-square.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Interface segregation principle
+
+== Interface segregation principle
+
+- Many client-specific interfaces are better than one general-purpose interface.
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Dependency inversion principle
+
+
+== Dependency inversion principle
+
+- One should depend upon abstractions, not concretions.
+- e.g. Data access layer in between controler and domain layer
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== DRY Principle
+
+
+== Don't Repeat Yourself (DRY)
+
+- "Every piece of knowledge or logic must have a single, unambiguous representation within a system."
+- Andy Hunt and Dave Thomas in their book The Pragmatic Programmer
+
+[.smalled-40]
+https://en.wikipedia.org/wiki/Don%27t_repeat_yourself  
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== KISS Principle
+
+== Keep It Simple, Stupid (KISS)
+
+- write simple code
+- if classes / methods become lengthy and complicated you need to consider refactoring
+** extracting code in separate classes methods
+** eliminate redundant code
+
+
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== UML
+
+[.smaller-80]
+== UML - Unified Modelling Language
+
+- 13 diagrams that show various perspectives on the system
+
+- purpose:
+** Stimulate and focus discussion about an existing or a new system
+** Document an existing system
+** Detailed description to generate a system
+
+- informal use of UML:
+** “I do not find UML to be useful during the design process itself and prefer informal notations that are quicker to write and that can be easily drawn on a whiteboard.” (Sommerville, s. 175)
+
+== !
+
+image::../images/lecture13/uml-diagrams.png[canvas, size=contain]
+
+[.smaller-20]
+[.left-30] 
+Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Package diagram
+
+[.smaller-80]
+== Package diagram
+
+- Gir en oversikt over avhengigheter mellom moduler av et system
+- Viser “pakker” - typisk grupper av klasser
+- Viser avhengigheter mellom pakker/moduler
+- Hver klasse er kun medlem av en “pakke”
+- Pakker representerer et hierarkisk navnerom, så hver klasse innen en pakke må ha et unikt navn
+- En pakke skal ikke kunne være medlem av flere moduler
+
+[.smaller-30]
+Fowler, Martin., (2003). UML distilled: a brief guide to the standard object modeling language. Pearson Education.
+
+
+== !
+
+image::../images/lecture13/package-diagram.png[canvas, size=contain]
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Class diagram
+
+
+== Class diagram
+
+- Viser typer objekter i systemet og statiske relasjoner mellom dem
+- Enkleste form: Klassenavn i bokser
+- Viser egenskaper (attributter, assosiasjoner) og operasjoner (metoder) for en klasse
+
+
+[.smaller-30]
+Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 149.
+
+== !
+
+image::../images/lecture13/class-diagram-1.png[canvas, size=contain]
+
+[.smaller-30]
+[.left-30]
+Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.
+
+
+== !
+
+image::../images/lecture13/class-diagram-2.png[canvas, size=contain]
+
+
+[.smaller-30]
+[.left-30]
+Kilde: Yngve Lindsjørn, Universitetet i Oslo: IN2000: Kravhåndtering, modellering & design.
+
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Sequence diagram
+
+[.smaller-80]
+== Sequence diagram
+
+- Brukes for å analysere samarbeid mellom objekter
+- Modellerer interaksjoner mellom aktører og objekter i et system og interaksjon mellom objekter i et scenarie
+- Aktører og objekter finnes øverst i diagrammet
+- Tidsakse nedover i diagram
+- Piler indikerer interaksjon mellom objekter
+- Annoterte piler indikerer metodekall
+- Kan vise alternative sekvenser
+
+[.smaller-30]
+Sommerville: Software Engineering, Pearson, 2016. 10th Edition, page 146.
+
+== !
+
+image::../images/lecture13/sequence.png[canvas, size=contain]
+
+== !
+
+```puml
+
+actor User
+User -> "~#newTodoItemButton: Button" as newTodoItemButton: click
+newTodoItemButton -> TodoController: handleNewTodoItemAction
+TodoController -> "~#newTodoItemText: TextField" as newTodoItemText: getText
+TodoController -> TodoList: addTodoItem
+TodoList -> TodoList: fireTodoListChanged
+TodoList -> TodoListListener: todoListChanged
+TodoListListener -> TodoController: autoSaveTodoList
+TodoListListener -> TodoController: updateTodoListView
+
+```
+
+[background-color = "#124990"]
+[color = "#fff6d5"]
+== Summary
+
+include::{includedir}footer.adoc[]
\ No newline at end of file