Home
Blog
About
Donate

CS261

Definitions Sheet

Back to the main page

Contents

  1. Dev Methodologies
  2. Requirements
  3. Design
  4. Project Management
  5. Implementation
  6. Human Computer Interaction
  7. Dependability
  8. Testing

Dev Methodologies

Waterfall

Requirements -> design -> implementation -> verification -> maintenance

Replan on change

Agile principles

  • Customer involvement - cannot respond rapidly to changes without rapid feedback
  • Incremental delivery - have prototypes, and update spec for next iterations
  • People not process - have highly skilled coders that know what they're doing. Share knowledge and improve processes
  • Embrace change - open to additions, and design system to accommodate change (hard)
  • Maintain simplicity - since there is a lack of good doucmentation, software must be simple and easy to understand for new members - "self commenting code" (lofty ideals)

Agile -> XP

Done around story cards, lots of customer involvement.

Agile -> Scrum

Planning stage -> sprint cycle -> project closure

sprint cycle

Requirements

Requirements engineering

C-facing, D-facing

C-facing reqs D-facing reqs
  • System from user view
  • how it works in natural language
  • diagrams are always nice
  • list of constraints in operation
  • Detailed descriptions of functionality
  • Language, service, protocols, libraries, etc
  • Defines exactly waht must be implemented

Requirement elicitation

  1. Interact with stakeholders, gather info
  2. Consider conflicts of interest
  3. Negotiation and clarifications
  4. Finalise document

Prioritisation done with MoSCoW: Must, Should, Could, Won't.

Design

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.

Project Management

Planning

Implementation

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.

  • Cuts down on repeated code
  • Adding new variations and scenarios is easier
  • Making changes and testing is also easier
  • Lots of new classes
  • Factory intrinsically linked to produced class -- when we update class, we must still update all associated factories

Creation: prototype

Problem: Same as above

Solution: Create a prototype object and just clone it, with an internal clone method.

  • Don't need to make subclass to create another object
  • Removes heavy initialisation code for cloning
  • Produces complex objects easily whilst keeping class heirarchy simple
  • Circular references are difficult to deal with
  • Update code still has to be done over all objects

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.

  • Can hide away parts of service object we don't want accessed
  • Manages object life cycle
  • Provides availability even if object itself not available
  • New proxies can be made without changing service
  • Added complexity
  • Another step between request and response -- overhead concerns

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.

  • Extend behaviour without subclasses
  • Responsibilities become dynamic at runtime
  • Combinable
  • Promotes single responsibility
  • Removing wrappers later is difficult
  • Generally very order dependent, and hard to implement to make it not so
  • Initial code layout can look messy and the whole setup can be rather hard to understand (*ahem* Spring)

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.

  • Promotes single responsibility
  • New adaptors can be introduced without heavy refactoring
  • Increased code complexity
  • Depending on size of codebase, converting the original object may be easier

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.

  • Saves memory, sometimes drastically
  • Some data may need to be recalculated for every call: tradeoff for increased CPU use
  • Increased complexity

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.

  • New subs can be added without redesigning publisher
  • Relationships between objects change at runtime
  • Subscribers notified in possibly random order

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.

  • Makes backups without violating encapsulation
  • Keep original object simple by extracting maintenance and restoration
  • Heavy memory cost
  • Need caretakers to track lifecycles, more classes
  • Dynamic languages can't guarantee state is preserved

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.

  • Can swap implementation at runtime
  • Separates algorithm from scaffolding code
  • Simplifies class heirarchy
  • Unnecessary when few choices
  • Requires clients to understand difference between strategies
  • Can just use lambda functions tbh

SOLID principles

  • Single Responsibility: each class does one thing
  • Open/Closed: open to extension closed to modification - once we finish a class, don't modify it again - extend it
  • Liskov Substitution: an object that uses a parent class can use its child classes without knowing -- child class can pretend to be parent class and serve all functionality of parent class
  • Interface segregation: many specific interfaces better than one generic interface -- no code should depend on methods it doesn't use
  • Dependency Inversion: ensure high level classes do not rely on functions from low level classes

    • Human Computer Interaction

    Nielsen's usability principles

    1. STATUS | Visibility of system status should always keep user informed on whats going on in reasonable amount of time
    2. MATCH | Match between system and real world use metaphors from the real world for intuition, follow conventions
    3. FREEDOM | User control and freedom need to permit people to back out / cancel actions at will
    4. CONSISTENCY | Consistency and Standards follow platform and industry standards for design
    5. PREVENT | Error prevention program to prevent errors from user mistakes, or add confirmations for error prone operations
    6. RECOVER | Recognise, Diagnose, and Recover from errors error messages should be in plain language, indicate the problem and suggest a solution
    7. RECOGNITION | Recognition rather than recall minimise user memory load by making actions and elements visible, information required should easily be retrievable
    8. EFFICIENCY | Flexibility and Efficiency of Use Shortcuts can speed up use for powerusers. Let people customise these.
    9. MINIMALIST | Aesthetic and minimalist design interfaces should not contain irrelevant or rarely needed information, focus on essentials
    10. DOCUMENTATION | Help and documentation provide easy to search documentation to help users

    Norman's action cycle

    • Form a goal - user first decides what they want to do
    • Intention to act - user makes intention explicit
    • Plannign to act - user chooses action from list of possible actions
    • Execution - user does the interaction
    • Feedback - user receives feedback from the world / system
    • Interpret feedback - user interprets the feedback based on what they expected to happen
    • Evaluate - user determines if they have been successful and are now closer to their goal

    -> principles of design

    • Provide visibility -- ensure user can easily understand current state of operations
    • Provide a good conceptual model -- ensure outcomes and results are consistently presented
    • Provide good mappings -- ensure easy to determine what the outcome of any action will be
    • Provide feedback -- ensure user gets constant and consistent feedback on results

    Gestalt Principles

    1. Figure Ground Principle: People segment their vision into "figure" and "ground" (i.e. fore and background). The figure gets the focus and is perceived as in front.
    2. Similarity Principle: Form informs function. If two things look similar, they'll probably behave similar. Can make use of colours and shapes in UI.
    3. Proximity Princple: If objects are grouped together, they're probably related. Proximity overrides similarity.
    4. Common Region Principle: Following from proximity, we group objects together in the same closed region -- what borders do. A UI will have several boxes and menus.
    5. Continuity Principle: If a series of objects are in a line or a curve, we think they are related. Curves and lines are better because we pattern match them quickly.
    6. Closure Principle: If we see a complex arrangement of shapes, likely to form them into a single pattern and fill in the blanks. ඞ
    7. Focal Point Principle: When we look at an image, we are drawn to the thing that stands out the most.

    Dependability

    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

    • Documentable: defined process model that sets out what documentation is needed
    • Standardised: processes applicable for many different systems, and should have standards applicable to all of them.
    • Auditable: understandable by people other than the users, so verification can be done
    • Diverse: include redundant and diverse validation/verification
    • Robust: should be able to recover from failures of individual models.

    On event of failure

    • Graceful degredation enables the system to still operate (perhaps in reduced capacity) when
    • Redundancy is where spare capacity is included in a system in case part of the system fails
    • Diversity making redundnant systems have different implementations, so they're less likely to fail similarly.

    Protection Systems

    Self-monitoring architectures

    Testing

    • Verification: does it meet spec?
    • Validation: does it meet needs of customer (which may be not as explicitly mentioned in the spec)?
    • Error: human action that produces incorrect result
    • Failure: software deviates from expected function
    • Defects/Bugs: manifestation of error in software, may cause failure
    • Testing: process of "excersising" software to ensure all requirements are met.
    • Test case: a series of inputs, preconditions, and expected outcomes to ensure compliance with a specific requirement.
    • Reliability: probability that software will not cause system failure for a specified time range and conditions
    • Test plan: record of applying test cases and the reasoning behind those cases
    • System testing: tests both funtional and nonfunctional requirements.

    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

    • Alpha testing for selected users on very early versions of software
    • Beta testing with a larger group of users with a more complete version
    • Acceptance testing for customers, to decide if the system is ready.

    Acceptance testing

    • Define acceptance criteria first of all, before the contract. May be difficult if requirements not in pace. This makes a test criteria.
    • Plan acceptance testing establishing testing schedule and resources, and coverage and order. This makes a test plan.
    • Derive acceptance tests which should be both functional and non-functional. Should cover all requirements. Carefully consider. This makes the tests.
      • Acceptance Tests define a "user journey" -- a series of steps a user might take -- and then its expected output.
    • Run acceptance tests ideally in the delopyment environment. Difficult to automate. Ideally involve users. This gets the test results.
    • Negotiate test results since unlikely that all acceptance tests will pass. Determine if the failures are negligible or important. This makes a test report.
    • Accept or reject system either go back for more development or done.