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
|
||||
---
|
||||
|
||||
[[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
|
||||
---
|
||||
|
||||
- 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
|
||||
---
|
||||
|
||||
|
||||
[[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/predictive-adaptive-spectrum]]
|
||||
- [[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-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