mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
auto update
This commit is contained in:
Jet Hughes
parent
10ef14ed80
commit
7ded6ab3a0
76
content/daily_notes/2022-04-07.md
Normal file
76
content/daily_notes/2022-04-07.md
Normal file
@ -0,0 +1,76 @@
|
|||||||
|
[[notes/daily-notes]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-07
|
||||||
|
|
||||||
|
<% tp.user.getAOTD() %>
|
||||||
|
|
||||||
|
| # | task | P | A | e time | r time |
|
||||||
|
|---| ------------------------|---|---|--------| ------ |
|
||||||
|
| 1 | | | | | |
|
||||||
|
| 2 | | | | | |
|
||||||
|
| 3 | | | | | |
|
||||||
|
| 4 | | | | | |
|
||||||
|
| 5 | | | | | |
|
||||||
|
| 6 | | | | | |
|
||||||
|
| 7 | | | | | |
|
||||||
|
| 8 | | | | | |
|
||||||
|
|
||||||
|
> SCORE:
|
||||||
|
|
||||||
|
## 1 Todos
|
||||||
|
- [ ] 12:00 Cosc201 lab
|
||||||
|
- [ ] 12:00 Info201 Lab
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 14:00 Cosc202 Lab
|
||||||
|
- [ ] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
|
||||||
|
<%*
|
||||||
|
const d = new Date().getDay()
|
||||||
|
switch(d){
|
||||||
|
case 1:
|
||||||
|
tR+="- [ ] 11:00 Cosc202 Lecture\n- [ ] 12:00 Cosc201 lab"
|
||||||
|
break;
|
||||||
|
case 2:
|
||||||
|
tR+="- [ ] 10:00 Info203 Lecture\n- [ ] 11:00 Cosc201 Lecture\n- [ ] 13:00 Info201 Lecture\n- [ ] 14:00 Cosc202 Lab"
|
||||||
|
break;
|
||||||
|
case 3:
|
||||||
|
tR+="- [ ] 10:00 Info203 Lecture\n- [ ] 14:00 Info203 Tutorial\n- [ ] 16:00 Cosc201 Tutorial"
|
||||||
|
break;
|
||||||
|
case 4:
|
||||||
|
tR+="- [ ] 11:00 Cosc202 Lecture\n- [ ] 12:00 Cosc201 Lab\n- [ ] 16:00 Info201 Lecture"
|
||||||
|
break;
|
||||||
|
case 5:
|
||||||
|
tR+="- [ ] 09:00 Cosc202 Lab\n- [ ] 11:00 Cosc201 Lecture\n- [ ] 12:00 Info201 Lab"
|
||||||
|
break;
|
||||||
|
default:
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
%>
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
|
||||||
|
### 6.1 cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
@ -4,4 +4,22 @@ tags:
|
|||||||
- info201
|
- info201
|
||||||
---
|
---
|
||||||
|
|
||||||
|
[[notes/approaches-to-systems-development]]
|
||||||
|
|
||||||
|
1. What are the two main approaches to systems development and how do they differ
|
||||||
|
|
||||||
|
[[notes/business-functions]]
|
||||||
|
2. What are business functions
|
||||||
|
|
||||||
|
3. What is a use case
|
||||||
|
|
||||||
|
4. What is a use case diagram used for
|
||||||
|
|
||||||
|
[[notes/use-case-diagrams]]
|
||||||
|
|
||||||
|
- dependencies
|
||||||
|
- includes
|
||||||
|
- excludes
|
||||||
|
- requries
|
||||||
|
|
||||||
|
what is the difference between requries and indludes
|
||||||
|
|||||||
@ -4,4 +4,12 @@ tags:
|
|||||||
- info201
|
- info201
|
||||||
---
|
---
|
||||||
|
|
||||||
|
- understand core onepts realted to business process mondelling
|
||||||
|
- learn about commonly used business process modelling notations
|
||||||
|
- understand the elemeents of a UML activity diagram
|
||||||
|
|
||||||
|
1. What is a business process
|
||||||
|
- [[notes/business-process]]
|
||||||
|
- [[notes/business-process-model]]
|
||||||
|
- [[notes/business-process-model-and-notation]]
|
||||||
|
- [[notes/UML]]
|
||||||
|
|||||||
@ -4,4 +4,4 @@ tags:
|
|||||||
- info201
|
- info201
|
||||||
---
|
---
|
||||||
|
|
||||||
|
[[notes/entity-relationship-diagrams]]
|
||||||
|
|||||||
118
content/notes/UML.md
Normal file
118
content/notes/UML.md
Normal file
@ -0,0 +1,118 @@
|
|||||||
|
---
|
||||||
|
title: "UML"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
A standard set of model constructs and notation defined by the object management group
|
||||||
|
|
||||||
|
specify what not how
|
||||||
|
|
||||||
|
- activity diagrams
|
||||||
|
- high level for business prcesses workflows
|
||||||
|
- low level for dtailed business logic
|
||||||
|
- advantages
|
||||||
|
- describe workflows
|
||||||
|
- specify relative processing rder of activites
|
||||||
|
- simple
|
||||||
|
- can be shown to stakeholders for checking and confirmation
|
||||||
|
|
||||||
|
enables implementation-independent specification of:
|
||||||
|
- user/system interactions
|
||||||
|
- partitioning of responsibility
|
||||||
|
- integration with larger or existing systems
|
||||||
|
- data flow and dependency
|
||||||
|
- order of operations (algorithms and processes)
|
||||||
|
- concurrent operations
|
||||||
|
|
||||||
|
## 1 why is is useful
|
||||||
|
- helps develop efficient effective correct designs
|
||||||
|
- better communication with project stakeholders
|
||||||
|
- gives a big picture view of the project system
|
||||||
|
- independent of specific programming languages or development processes
|
||||||
|
- de facto standard for modelling OO systems
|
||||||
|
|
||||||
|
## 2 what it is not
|
||||||
|
- visual modelling software
|
||||||
|
- a programming languages
|
||||||
|
- a software development process, method, or methodology
|
||||||
|
|
||||||
|
## 3 Types of diagram
|
||||||
|
### 3.1 structural
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.2 behavioural
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.3 Linked diagrams
|
||||||
|
each digram type models a dfiferenct aspect of the system
|
||||||
|
many of the diagrams link to each other
|
||||||
|
- e.g., use case, sequence, activity
|
||||||
|
- e.g., object, communication
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.4 Activites and transitions
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
- activities
|
||||||
|
- take place over some pariod of time
|
||||||
|
- linked by transitions (arrows)
|
||||||
|
- only one starting point potentaily many ending conditions
|
||||||
|
|
||||||
|
- Transitions
|
||||||
|
- have guard conditions that must be satisfied before the transition can occur
|
||||||
|
|
||||||
|
### 3.5 Decision points
|
||||||
|
- represent conditional branching
|
||||||
|
- two or more alternative transitions depending on condition
|
||||||
|
- every transiiton exiting the decision point must have a guard condition
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.6 Synchonisation bars
|
||||||
|
- represents two or more activites running in parallel
|
||||||
|
- transitions can be split into mutiple paths and recombined later
|
||||||
|
- if a workflow is split then it must be recombined on the same diagram
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.7 swim lanes
|
||||||
|
- same as BPMN
|
||||||
|
- show who is responsible for a process
|
||||||
|
- can represent
|
||||||
|
- business organisations
|
||||||
|
- depts
|
||||||
|
- people (actors)
|
||||||
|
- can simplify processes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.8 relationships to use cases
|
||||||
|
- use case diagrams show the high level interactions between actors and cases
|
||||||
|
- high level activity diagrams show the sequence of use cases within a workflow
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 3.8.1 example
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.9 Example producing a book
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
18
content/notes/approaches-to-systems-development.md
Normal file
18
content/notes/approaches-to-systems-development.md
Normal file
@ -0,0 +1,18 @@
|
|||||||
|
---
|
||||||
|
title: "approaches-to-systems-development"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1 traditional
|
||||||
|
regardless of the approach, the conecpot of the model is import for analysis design and modelling parrasigms
|
||||||
|
|
||||||
|
### 1.1 system is a collection of process
|
||||||
|
function programming
|
||||||
|
processes interact with data
|
||||||
|
processes accept inputs and produce ouputs
|
||||||
|
|
||||||
|
### 1.2 object oriented
|
||||||
|
system is a collection of objects
|
||||||
|
these objects interact with each other
|
||||||
|
and send and respond to messages
|
||||||
39
content/notes/business-functions.md
Normal file
39
content/notes/business-functions.md
Normal file
@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "business-functions"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
- what the business ought to be doing
|
||||||
|
- _not_
|
||||||
|
- who, how, stucture, tech
|
||||||
|
|
||||||
|
each business function becomes a set of features within an info system
|
||||||
|
|
||||||
|
## 1 Id business functions
|
||||||
|
- verb phrases
|
||||||
|
- id what the business ought to be doing ⇒ e.g., "accept payment from customer"
|
||||||
|
- id how => "we accept payments online banking and credit card"
|
||||||
|
- always ask "what is the objective"
|
||||||
|
- remove redundancies
|
||||||
|
- model the id'd functions as _use cases_
|
||||||
|
|
||||||
|
## 2 Use case
|
||||||
|
"A list of actions defining the interactions betweeen a role and a system to achiece a goal"
|
||||||
|
|
||||||
|
high level description of how people interact with a system
|
||||||
|
|
||||||
|
story of how the business works
|
||||||
|
|
||||||
|
should be:
|
||||||
|
- simple
|
||||||
|
- aimed at stakeholders
|
||||||
|
- understandable by non-tech people
|
||||||
|
- should use ubiquitous language
|
||||||
|
- also useful for system devs
|
||||||
|
|
||||||
|
can use text (Cockburn, fowler) or diagrams (function catalog, UML case diagrams)
|
||||||
|
|
||||||
|
## 3 UML
|
||||||
|
unified modeling language
|
||||||
|
- use case - class - state - activity - sequence - deployment etc
|
||||||
30
content/notes/business-process-model-and-notation.md
Normal file
30
content/notes/business-process-model-and-notation.md
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "business-process-model-and-notation"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
BPMN
|
||||||
|
|
||||||
|
- graphical diagramming language
|
||||||
|
- free international vendor standard developed by the object management group
|
||||||
|
- shows only the order of activites
|
||||||
|
- when, not under what conditions
|
||||||
|
- do not:
|
||||||
|
- detail the activites
|
||||||
|
- describe how it is informed
|
||||||
|
|
||||||
|
## 1 Components
|
||||||
|
### 1.1 swimlanes
|
||||||
|
identify the business role for each activity
|
||||||
|
|
||||||
|
### 1.2 Other features
|
||||||
|
- looping back
|
||||||
|
- types of branch gateway
|
||||||
|
- parallel execution
|
||||||
|
- collaboration with external entities (pools)
|
||||||
|
- executable if using the right infrastructure
|
||||||
|
|
||||||
|
## 2 Examples
|
||||||
|
|
||||||
|
|
||||||
20
content/notes/business-process-model.md
Normal file
20
content/notes/business-process-model.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
---
|
||||||
|
title: "business-process-model"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
- graphical depiction fo one ormore business proccesses
|
||||||
|
- some variant of a flowchart
|
||||||
|
- many different approaches
|
||||||
|
- BPMN
|
||||||
|
- UML activity diagrams
|
||||||
|
- data flow diagrams DFDs
|
||||||
|
- good for security
|
||||||
|
- business process execution language BPEL
|
||||||
|
- prgramm how a proces with go
|
||||||
|
- can be executed
|
||||||
|
- subject oriented business process mangement (s-BPM)
|
||||||
|
- and many more
|
||||||
|
- may be execultable
|
||||||
|
- developed alongside data models (ERDs, class diagrams etc)
|
||||||
30
content/notes/business-process.md
Normal file
30
content/notes/business-process.md
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "business-process"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
- A sequence of tasks or steps required to carry out a particular business function e.g.,:
|
||||||
|
- pocure new assets
|
||||||
|
- apply for leave
|
||||||
|
- process and orer
|
||||||
|
- enrol a student
|
||||||
|
- paper and or computer based processes
|
||||||
|
- processes can have sub-processes ⇒ nested hierarchy
|
||||||
|
- terminology
|
||||||
|
- business processes are also know as workflows
|
||||||
|
- activity usually means the same thing as tasl
|
||||||
|
|
||||||
|
**example: processing an order**
|
||||||
|
1. sales dept recieves and enters order into system
|
||||||
|
1. system triugger automated credit check bu finance dept
|
||||||
|
2. if credit not OK, STOP order
|
||||||
|
2. warhouse staff fulfill order
|
||||||
|
1. check availability in warehouse
|
||||||
|
2. if any item out of stick transfer to back order process
|
||||||
|
3. pack items for shipping
|
||||||
|
3. finance dept generated invoice
|
||||||
|
4. send shipment and invoice to customer
|
||||||
|
|
||||||
|
|
||||||
|
e.g., www.otago.ac.nz/study/enrolment/index.html
|
||||||
48
content/notes/entity-relationship-diagrams.md
Normal file
48
content/notes/entity-relationship-diagrams.md
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "entity-relationship-diagrams"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
cardinality
|
||||||
|
identifying vs non identifying relationship
|
||||||
|
|
||||||
|
labels are important - but not always needed
|
||||||
|
|
||||||
|
associative entity => changes many to many relationship with additional relationship
|
||||||
|
|
||||||
|
## 1 subtypes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
uses:
|
||||||
|
- model mutual exclusivity
|
||||||
|
- better for modelling not for implementation
|
||||||
|
|
||||||
|
## 2 parallel relationship
|
||||||
|
|
||||||
|
|
||||||
|
could model as separate relationships via staff subtypes
|
||||||
|
not very common
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
also an example of recursive many-to-many relationships
|
||||||
|
|
||||||
|
## 3 recursive relationship
|
||||||
|
labels are critical
|
||||||
|
usually 1:M can be 1:1 or M:M
|
||||||
|
|
||||||
|
|
||||||
|
## 4 dealing with data history
|
||||||
|
|
||||||
|
|
||||||
|
could be many to many relationships:
|
||||||
|
|
||||||
|
so associative relationship: 
|
||||||
|
|
||||||
|
what do we require:
|
||||||
|
- for the current point in time
|
||||||
|
- an histroical record how ⇒ must be selecetive to not use up to much space
|
||||||
@ -12,3 +12,6 @@ tags:
|
|||||||
- [[notes/agile-development]]
|
- [[notes/agile-development]]
|
||||||
- [[notes/predictive-adaptive-spectrum]]
|
- [[notes/predictive-adaptive-spectrum]]
|
||||||
- [[notes/requirements-elicitation]]
|
- [[notes/requirements-elicitation]]
|
||||||
|
- [[notes/approaches-to-systems-development]]
|
||||||
|
- [[notes/business-functions]]
|
||||||
|
- [[notes/use-case-diagrams]]
|
||||||
|
|||||||
@ -9,10 +9,3 @@ tags:
|
|||||||
|
|
||||||
- [[notes/info-201-outline]]
|
- [[notes/info-201-outline]]
|
||||||
- [[notes/info-201-lectures]]
|
- [[notes/info-201-lectures]]
|
||||||
|
|
||||||
## 1 Assignments
|
|
||||||
|
|
||||||
-
|
|
||||||
|
|
||||||
## 2 Resources
|
|
||||||
|
|
||||||
|
|||||||
113
content/notes/use-case-diagrams.md
Normal file
113
content/notes/use-case-diagrams.md
Normal file
@ -0,0 +1,113 @@
|
|||||||
|
---
|
||||||
|
title: "use-case-diagrams"
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
- specifies the participants (actors) and the relationships between them
|
||||||
|
- high level view of what a system does (not how) and who uses it
|
||||||
|
- represent users perspective of a system
|
||||||
|
- used mainly in requirements specification and early system dev
|
||||||
|
- effectively a todo list
|
||||||
|
|
||||||
|
## 1 pros
|
||||||
|
+ informal,flexible, easy to construct
|
||||||
|
+ easily understood
|
||||||
|
+ improve communication between users and developers
|
||||||
|
+ can be used to confirm requirements
|
||||||
|
+ provide overview
|
||||||
|
+ link analysis to design
|
||||||
|
+ can be used to inform subsequent dev tasks
|
||||||
|
+ derive test cases
|
||||||
|
+ prioritise imlementation tasks
|
||||||
|
+ help clarify new feature requests or bug reports
|
||||||
|
|
||||||
|
## 2 Notation
|
||||||
|
|
||||||
|
### 2.1 Actor
|
||||||
|
- roles that people have when interacting with the system
|
||||||
|
- external systems or hardware that are essential to system operation
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.2 Use case
|
||||||
|
- discrete unit of system functionality
|
||||||
|
- activity from perpective of an actor
|
||||||
|
- can be abstract or focused
|
||||||
|
- say nothing about flow or behaviour
|
||||||
|
- map to ⇒ menu items, forms, reports, etc
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.3 Association
|
||||||
|
- relationship (interaction) between actor and use casel
|
||||||
|
- actor can be associated with more than one use case
|
||||||
|
- use case can be associated with more than one actor
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.4 Specialisation/generalisation
|
||||||
|
- actors and use cases can be orgainsed into special/general hierachies
|
||||||
|
- acotrs can be specialisations of another actor
|
||||||
|
- same for use cases
|
||||||
|
- mutually exclusive
|
||||||
|
- similar to inheritance
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.5 Dependency
|
||||||
|
- occur between use cases
|
||||||
|
- one case extends the behaviour of another
|
||||||
|
- one case includes the behabiour of another
|
||||||
|
- one case requires the behaviour of another
|
||||||
|
- read in direction of arrow
|
||||||
|
- indicate opportunities for reuse of functionality
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 2.5.1 Extends dependency
|
||||||
|
- use cases can have optional, subordinate tasks
|
||||||
|
- useful with specialised actors
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 2.5.2 Includes dependency
|
||||||
|
- use cases that have mandatory, subordinate tasks
|
||||||
|
- does not indicate sequence, only that they must happen
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 2.5.3 Requires dependency
|
||||||
|
- mandatory, _independent_ tasks, that must be completed first
|
||||||
|
- forces sequence
|
||||||
|
- use sparingly
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 3 development of use case diagrams
|
||||||
|
organise related use case diagrms itno use case model
|
||||||
|
- have have multiple levels of detail
|
||||||
|
- group related diagrams into packages
|
||||||
|
|
||||||
|
### 3.1 example methods
|
||||||
|
- user goal technique ⇒ simple
|
||||||
|
- event decompositition technique ⇒ more comprehensive
|
||||||
|
|
||||||
|
### 3.2 top down
|
||||||
|
identify actors ⇒ identify use cases ⇒ detail use cases
|
||||||
|
- who will enter and/or recience information
|
||||||
|
- what other systems will interact with the system
|
||||||
|
- prioritise use cases
|
||||||
|
- further develop use case, starting with highest priority
|
||||||
|
- structure overall use case model
|
||||||
|
|
||||||
|
> **avoid specifying the sequence**
|
||||||
|
|
||||||
|
### 3.3 bottom up
|
||||||
|
create scenario ⇒ generalise scenario ⇒ organise use case model
|
||||||
|
|
||||||
|
## 4 Examples
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user