Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

CS 361 > Final Prep > Flashcards

Final Prep Flashcards

1
Q

When did Agile really start taking off

A

about 13 years ago (2005)

before, we used waterfall

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Uncle Bob Video:

A

smaller iterations and constant feedback (like a RD in writing)

don’t let yourself get blocked by anything

delay decisions with good architecture. make business rules early and defer everything else

no grand redesigns. just clean up a little each time

say no to things. choose good code over meeting deadlines

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

When did Test-Driven Development (TDD) really start taking off?

A

8 years ago

you don’t want to be good at debugging

tests bring enthusiasm and sense of accomplishment

continuous stream of quality documentation

cost and risk of making changes goes way down. code is sensitive on the one-bit level. other things in life aren’t like this
– TDD is like double-entry bookkeeping in accountancy

tests must be automated

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

“decoupled code”

A

testable code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

INVEST - [ I ]

User Stories.

A

Independent

not always possible but good thing to seek

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

INVEST - [ N ]

User Stories.

A

Negotiable

conversation to be had

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

INVEST - [ V ]

User Stories.

A

Valuable

to the user

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

INVEST - [ E ]

User Stories.

A

Estimable

should be small/discrete enough that a decent timeframe can be given

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

INVEST - [ S ]

User Stories.

A

Small

big = not estimable

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

INVEST - [ T ]

User Stories.

A

Testable

able to create definition of done
acceptance criteria established

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Three components of a user story

A

CARDS (physical medium)

CONVERSATION (discussion surrounding)

CONFIRMATION (tests to verify)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

SMART - [ S ]

Tasks.

A

Specific

Everyone knows what’s involved. Tasks don’t overlap. Can determine whether it fits within the bigger plan.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

SMART - [ M ]

Tasks.

A

Measurable

Do you know when it’s done

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

SMART - [ A ]

Tasks.

A

Achievable

No person should have a task too difficult for them to complete. And everyone should be able to ask for help if it’s not doable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

SMART - [ R ]

Tasks.

A

Relevant

Fits into the bigger story. Stories are broken up for the sake of developers. Should be able to explain to a customer why a task is relevant though.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

SMART - [ T ]

Tasks.

A

Time-Boxed

doesn’t have to be a formal, strict estimate, but there should be expectations so that people know when they need to seek help/split up a task

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Core Design Principles of Java

A

platform independent

  • JVM is an abstraction and programs do not access the OS directly
  • high portability

object-oriented
- except primitive data types, all elements are objects

strongly-typed
- variables are pre-defined and conversion is relatively strict

interpreted and compiled

  • source code is transferred into bytecode format
  • these instructions are interpreted by the JVM
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

A Few More Basics of Java

A
  • syntax heavily influenced by C++
  • statically typed
  • imperative language
  • criticized for being verbose
  • most-used language according to GitHub
  • owned by Oracle
  • visibility (scope) is the same as in C++
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

A few predefined classes in Java

A

String, Vector, Stack, Hashtable, and many others

A Stack is a subclass of Vector which is a subclass of Object. All classes in Java are subclasses of the class Object.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Java “field”

A

= variable

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Java “method”

A

= function

methods can be overloaded with one name referring to multiple methods (params/return val/etc different)

abstract methods (from polymorphic abstract object) have to be overwritten/cannot have an implementation
public interface Driveable { }
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Git

A

Distributed version control system

“upstream” is your teams repository after forking

rebase = alternative to git merge master (produces cleaner history)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

TDDs’ three rules

A

Write a failing test before writing any production code

don’t write more of a test than is sufficient to fail/fail to compile

don’t write more production code than is sufficient to make the currently failing test pass

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

The TDD cycle

A

RED (fail test)
GREEN (production code)
REFACTOR

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Why TDD?

A

Design and documentation more than it is verification

close feedback loops

clear starting points

throw away less code

worry about I/O less

more confidence

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

non-functional requirements

A

SLA’s (Service Level Agreement)

quantitative

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

functional requirements

A

what it needs to do

system behavior when interacted with

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

User Story basics

A

plain english

As a ____, I want ____ so that ______

3x5 index
stick to wall/whiteboard

have conversation with product owner

confirmation written on back of the card

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

functional decomposition

A

programs (like C) are decomposed into functions, that operate on common data structures

as opposed to OO-decomposition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

object oriented decomposition

A

A system is decomposed according to the objects a
system is supposed to manipulate (like Java)

Objects communicate through well defined
interfaces

as opposed to functional decomposition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Encapsulation

A

Group together data (variables) and methods
(functions) in one unit

all variables should be hidden (private) and
only accessible by the methods in the class

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Inheritance

A

Also known as subclassing or subtyping

Classes inherit fields and methods with the extends keyword

Java only supports single inheritance (you can only
extend from one class)
– all roots trace back to the Object class

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Polymorphism

A

subclass can always be used instead of parent class

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

SOLID - [ S ]

Object-Oriented Design.

A

Single Responsibility Principle (SRP)

class has only one responsibility/reason to change

class should only know about one thing; it should only act like one logical object

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

SOLID - [ O ]

Object-Oriented Design.

A

Open-Closed Principle (OCP)

classes should be closed for modification, open for extension

when new requirements, add code instead of changing code

examples: chrome extensions, IDE plugins, OS drivers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

SOLID - [ L ]

Object-Oriented Design.

A

Liskov Substitution Principle (LSP)

subclass has contract with parent to do everything it does

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

SOLID - [ I ]

Object-Oriented Design.

A

Interface Segregation Principle (ISP)

only use classes you need

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

SOLID - [ D ]

Object-Oriented Design.

A

Dependency Inversion Principle (DIP)

depend on abstractions not concretions

“Message” from “text message” and “email message”

“Ship” from _____

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

formal inspection code review

A

expensive. long. heavyweight. Michael Fagan in the 70s

4 roles 7 stages

9 person-hours per 200 lines of code

40
Q

lightweight approaches to code reviews

A

over the shoulder

pair programming

pull requests

41
Q

code review suggestions

A

< 400 lines at once

< 60 minutes at a time

peer review checklist

follow up on comments

42
Q

verification vs validation

A

VALIDATION :: are we building what we should be building?

  • Acceptance testing
  • User demos
  • Beta testing

VERIFICATION :: are we building that thing right?

  • Formal methods
  • Unit tests
  • Regression tests
43
Q

Types of testing

A

development - done during dev by developers and testers

release - done prior to release or other milestone. done outside dev team (e.g. the customer)

user - users (beta testing)

integration - components interact as expected

regression testing - make sure bugs reappear

44
Q

JUnit basics

A

in Maven, src/test/java

each production class has a test class and they live in the same package

annotate test methods with @Test (line before)

annotate with @Before to setup - sets up a “test fixture,” which is the context in which a test is run

@After to release resources after a test

@BeforeClass and @AfterClass to do test fixture setup/teardown only once per class run (bookends of the entire file)

org.junit.Assert

JUnit executes tests in a deterministic, but
unpredictable order (independence assumption of tests)
45
Q

Blackbox and whitebox

A

blackbox

  • you don’t know the implementation
  • tests are derived from specifications/documentation/etc.

whitebox = you do
- trying to execute all lines of the code, branches, conditionals, etc.

46
Q

equivalence class partitioning (blackbox)

A

try things that are basically representative of all inputs

47
Q

boundary testing (blackbox)

A

like equivalence class partitioning (ECP), but more focused on boundaries

48
Q

statement/line coverage (whitebox)

A

how many (executable) statements were covered?

does not mean 100%, because you could cover all lines, but not all branches

49
Q

branch coverage (whitebox)

A

all decision points are exercised

all choices in switch/conditional statements are covered

50
Q

path coverage (whitebox)

A

similar to branch coverage but takes it a step further, not only ensuring that all branches are covered, but all paths possible prior to reaching that branch.

if there’s a theoretically unlimited loop, 100% is impossible

51
Q

Nielsen’s Usability Goals

MEELS

A
  1. Memorability
    - Easy to remember after learning? Pick back up easily after gone awhile.
  2. Efficiency
    - Once it has been learned, how effective is it? How many clicks away?
  3. Errors (safety)
    - How easy to crash/break/reach state of perceived fear?
    - Check before deleting/etc.
  4. Learnability
    - Do you need manuals and courses to learn it?
  5. Satisfaction
    - Important with video games
52
Q

Heuristic Evaluation

A
  1. Visibility of system status
    - user knows what is happening
  2. Match between system and real world
    - intuitive by imitating the real world
  3. User control and freedom
  4. Consistency and standards
    - similar across platforms
  5. Error prevention
  6. Recognition rather than recall
    - minimize cognitive load by maintaining task-relevant information within display
    - assist the user in remembering things
  7. Flexibility and efficiency of use
    - expert can use more efficiently/powerfully
  8. Aesthetic and minimalist design
  9. Help users recognize, diagnose and recover from errors
    - tell them what the error is in plain English
  10. Help and documentation
53
Q

Code, methods and classes that have increased to

such gargantuan proportions that they are hard to work with

A

Bloaters

Long Method/Class/Param List

method longer than 10 is suspicious. longer than 30 is problematic

more than 4 params is too many. indicator of inadequate abstraction

check for code preceded by comments, long switch/conditionals

54
Q

Incomplete or incorrect application of object-oriented

programming principles

A

OO Abusers

use not all inherited fields/methods

complex switch = bad class hierarchy

55
Q

Any change requires you to make many

changes in other places too

A

Change Preventers

single responsibility has been distributed

56
Q

Something pointless whose absence would

make the code better

A

Dispensables

duplicated code

data class

speculative generality (unused. “just in case” stuff)

57
Q

Excessive coupling between classes

A

Couplers

feature envy (method accesses data of another more than its own)

inappropriate intimacy (one class uses internal fields and methods of another) good classes know as little as possible about one another

58
Q

Refactoring

A

give new stuff meaningful name

extract stuff into another class

take repeatedly passed parameter and make it a field

if multiple parameters belong to another object, just pass the object

replace inheritance with delegation (extract common behavior then delegate methods to that class)

move method

move field

pull up method (move to superclass)

collapse hierarchy - remove unused abstract

inline class - remove unnecessary classes

unused fields and methods simply removed

59
Q

Responsibility Driven Design (RDD)

A
  1. find the classes in your system
  2. determine the responsibilities of each class
  3. determine how objects collaborate with each other to fulfill their responsibilities
  4. factor common responsibilities to build class hierarchies
60
Q

Assigning Responsibilities

A

Be lazy (don’t do anything you can push to someone else)

Be tough (don’t let others play with your toys)

Be socialist (evenly distribute system intelligence)

61
Q

CRC

A

Class-Responsibility-Collaborator

class name (top)
responsibilities (left)
collaborators (right)

62
Q

Responsibilities

A

can class fulfill responsibility by itself?

if not, what does it need, and from what class can it obtain that?

63
Q

For each class

A

What does this class know?

What other classes need its information or results?

Classes that do not interact with others should be discarded

64
Q

UML

A

Unified Modeling Language

design

high-level picture

communication

vocabulary

teaching

65
Q

classes of UML diagrams

A

Behavior
- activity, sequence, state machine

Structure
- elements irrespective of time

66
Q

Activity Diagram

A

start with black circle

rounded rectangle = action

diamond = decision

black bar = concurrent activities

end with black circle with ring

67
Q

Sequence Diagram***

A

how processes operate and in what order

asynchronous code

usage scenarios, logic of methods, logic of services

each actor is a labeled vertical line

each message is a horizontal line with message name written above the line

open arrow heads represent async messages

dashed line = response

68
Q

State Diagram

A

states of an object

normal state

start/initial state

stop/accepting/final state

transition

69
Q

actions vs activities

A

actions quick and not interruptible
associated with transitions

activities associated with states, take longer, and can be interrupted

70
Q

Use Case Diagrams

A

user interaction

summary of usage requirements from user’s point of view

71
Q

Class Diagrams***

A

Name
Attributes (fields)
Operations (methods)

fixed numbers on lines or ranges with a “..” including * for “any”

72
Q

Dotted line to an arrow

A

Association class

73
Q

Filled Arrow

A

Employee works in => Office

most common

74
Q

Empty Arrow

A

Inheritance

75
Q

Filled Diamond

A 
composition 
(engine is a part of a car)
(catalog is a part of library)
part can't exist outside of the whole
tear down a visitor center and the lobby and bathroom get destroyed in the process
76
Q

Empty Diamond

A

aggregation
(person goes in a car)
can exist outside the whole by itself or be a part of the whole. tortoise a part of the “creep”

77
Q

Four elements that describe a design pattern

A

Name
Purpose (problem it solves)
Solution
Constraints (that we consider in our solution)

78
Q

Three categories of design patterns

A

Creational
abstract away the object instantiation (creation)

Structural
concerned with how classes and objects are composed to form larger structures

Behavioral
concerned with how algorithms and the assignment of responsibilities between objects

79
Q

Singleton

Creational

A

ensure one instance and provide global point of access to it

make the constructor private

if (s == null)
    s = new Singleton()
80
Q

Factory Method

Creational

A

creates an instance of several derived classes

define interfaces for creating an object. let subclasses decide which class to instantiate

framework instantiates the objects

the instantiated objects are sometimes knows as
products

Transport object = logistics.makeInstance();
and this decides whether road or sea transport

complex, but makes adding new products easy and follows OCP

81
Q

Composite

Structural

A

a tree structure of simple and composite objects

compose objects into tree structures to
represent part-whole hierarchies. Clients can treat
individual objects and compositions uniformly

A file system has files and folders. Users
want to manipulate files and folders the same way
(e.g. move, rename, delete etc)

Different but they still want to share some same capabilities

82
Q

Facade

Structural

A

a single class that represents an entire subsystem

unified interface to a set of
interfaces in a subsystem

higher-level
interface that makes the subsystem easier to use

83
Q

Template

Behavioral

A

define a skeleton of an algorithm and defer
some steps to subclasses

The base class provides the basic steps of the
algorithm.
The subclasses provide the details
84
Q

Observer

Behavioral

A

Define a one-to-many relationship between
objects, so that when one object changes its state,
the dependents are notified and updated
automatically

85
Q

Command

Behavioral

A

encapsulate a command request as an object

86
Q

State

Behavioral

A

Alter an object’s behavior when its state changes

87
Q

Chain of responsibility

Behavioral

A

Pass a request between a chain of objects

88
Q

Visitor

Behavioral

A

Define a new operation to a class without change

89
Q

4+1 Architectural View

A

Logical View:
functionality to end users.

Process View:
runtime behavior, including processes and their
communication

Development View:
perspective of the developer management, maintenance etc;

Physical View:
deployment on actual physical hardware

90
Q

Monolith Architecture

A

single-tier software application

components in a single application

91
Q

Client-server Architecture

A

distributes functionality of a system into services

92
Q

Micro-service Architecture

A

extreme generalization of client-server architecture

93
Q

RESTful Architecture

A

inspired by the largest distributed application ever: The Web

stateless requests

every resource has individual URI (uniform resource identifier)

uniform interface for all resources (GET, POST, PUT, DELETE)

structure of response not specified

94
Q

3-Tier Architecture

A

client server architecture,
where the

[ application layer ]
functional
process logic (business logic),

[ data access layer ]
data persistence
(data access, storage management) and

[ presentation layer ]
user interfaces

are developed a 3 separate modules

95
Q

Layered Architecture

A

subtasks, where each group of subtasks is at a particular layer of abstraction

each layer provides set of services to layer “above”

Generic
Online Library
OSI reference
Android

96
Q

Event Driven Architecture

A

components perform services in reaction to external events generated by other components

In broadcast models an event is broadcast to all
sub-systems

In interrupt-driven models real-time interrupts are
detected by an interrupt handler and passed to
some other component for processing

CS 361 (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions