93 lines
3.0 KiB
Markdown
93 lines
3.0 KiB
Markdown
# 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.
|
|
|