Add dms lecture notes
This commit is contained in:
92
docs/lectures/dms/02_uml.md
Normal file
92
docs/lectures/dms/02_uml.md
Normal file
@@ -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**
|
||||
|
||||

|
||||
|
||||
|
||||
**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.
|
||||
|
||||
Reference in New Issue
Block a user