Waterfall
Requirements -> design -> implementation -> verification -> maintenance
Replan on change
Agile principles
Agile -> XP
Done around story cards, lots of customer involvement.
Agile -> Scrum
Planning stage -> sprint cycle -> project closure
Requirements engineering
C-facing, D-facing
C-facing reqs | D-facing reqs |
---|---|
|
|
Requirement elicitation
Prioritisation done with MoSCoW: Must, Should, Could, Won't.
UML
Static vs behavioural diagrams. Mathematical/logical system modelling language.
Static is like class diagrams, and use case diagrams. Dynamic is like activity, and sequence.
Just read this bit for the diagrams.
Planning
Design Patterns
4 aspects: (1) a meaningful name, (2) a description of problem, (3) a solution, (4) statement of drawbacks
Creation: factory
Problem: Deal with the tedium and sometimes inflexibility of manual object creation code.
Solution: Delegate object creation to centralised factory objects (or methods), which essentially handles object creation internally, and returns a completed object.
Creation: prototype
Problem: Same as above
Solution: Create a prototype object and just clone it, with an internal clone method.
Structural: proxy
Problem: Certain objects take a lot of processing power, or memory, or network bandwidth to load, which impacts performance should it be repeatedly fetched.
Solution: Create a proxy object, that references an entity without loading the entire object. Only load on demand.
Structural: Decorator
Problem: Adding multiple, often changing or diverse functionality to an object requres an often infeasible number of sublcasses.
Solution: Wrap classes in decorator classes, which effectively go "around" the base class and give it extra functionality, by doing extra logic around original class methods. We can thus change and add functionality dynamically.
Structural: Adaptor
Problem: The output of one object cannot be used immediately by another.
Solution: Have a glue class that takes output from one class, transforms it into something that another class can take.
Structural: Flyweight
Problem: Sometimes, many objects have very large assets (like textures), which take up a lot of memory, since each object has its own copy.
Solution: Extract large objects into a single data object, and have all objects reference that one data store.
Behavioural: Iterator
I don't think this needs to be explained?
But worth to mention that we can iterate multiple ways in parallel, and can even pause iteration.
Behavioural: Observer
Problem: Want some way of automatically notifying subscribers of some remote change.
Solution: either a push model (sender sends) or a pull model (receiver asks). Refer to sender as publisher and receiver as subscriber
Also has the ability for subscribers to be added and removed. opt-in functionality.
Behavioural: Memento
Problem: Want to save and restore objects without revealing implementation details (and thus maintaining encapsulation)
Solutution: Have the object in question implement a "memento" method to return a snapshot of itself, to be stored in a caretaker class.
Behavioural: Strategy
Problem: We want a program to change solutions dynamically for solving a problem.
Solution: Have strategy classes and a context controller object, which can dynamically pick strategies.
SOLID principles
Nielsen's usability principles
Norman's action cycle
-> principles of design
Gestalt Principles
Reliability
Reliability is a measure of how likely a system will work over a set period of time.
Perceived Reliability is how it seems to the user. May differ from real reliability since problems more likely with less used functions.
Dependable processes are
On event of failure
Protection Systems
Self-monitoring architectures
Static testing
Static testing is testing without execution. I.e. code inspection, verification
Dynamic testing
Dynamic testing is executing code with given test cases. It also involves validation.
statement adequacy is when all statements have been executed by at least one test. Statement coverage is then \(\frac{\textrm{number of executed statements}}{\textrm{number of statements}}\).
Unit testing
Tests individual functions and classes
Component, System testing
Testing whole system -- unit testing cannot catch interactions between components.
TDD
Test driven Development (TDD) is when tests are written first for an increment code, and then writing the code to pass the test.
User testing: stages
Acceptance testing