Brainscape's Knowledge GenomeTM

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


See full index

CS 361 > Final > Flashcards

Final Flashcards

1
Q

Requirements

A

state the purpose of the system. Expression of desired behavior

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

Typical parts of requirements documentation

A
  1. Functional requirements
    - unstructured text
    - use cases
  2. Nonfunctional requirements
    - unstructured text
    - use cases
  3. Diagrams
    - self explanatory
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Requirements definition

A

Stated from the viewpoint of someone outside of the system. Role of the system

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

Requirements specification

A

Stated from the viewpoint of someone inside the system. How the system works

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

External viewpoint

A

Stated from someone outside the system

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

Internal viewpoint

A

Stated from someone inside the system

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

Whats in a basic use case

A 
Use case name: Name of the case
Actor: Who/what is using it
Preconditions: 
Postconditions:
Flow of events: The steps taken in the system
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

non-functional requirements

A

Describe how well the system should do something. in terms of fit criteria

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

Use case diagram

A

Shows supported activities

  1. Stick man for user
  2. Ovals for cases
  3. Simple arrows when UC calls another
  4. Hollow arrowheads for specialization
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

UML class diagrams

A

Show entities, attributes relationships

  1. One box per kind of activity
  2. Lines with arrowheads show references
  3. Lines with hollow arrowheads for specialization
  4. Lines with regular arrowheads indicate dependencies
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Dataflow diagram

A

Shows flow of information

  1. Each oval is a function
  2. Each rectangle is an actor
  3. Each half rectangle is a datastore
  4. Separate for use cases
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Message sequence diagram

A

Shows flow of control

  1. One box per entity involved
  2. Arrows show messages
  3. Conditionals are written with brackets []
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

State chart

A

Shows change over time

  1. One box per state
  2. Arrows show state transition
  3. Filled circles show where you start
  4. nested circles show where you stop
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Entity relationship diagrams

A
  1. Database design
  2. One box per entity
  3. List entities on branches
  4. Numbers or variables on lines show cardinality
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Architecture

A

Shows a piece of a system and their relationships

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

Component

A

Self contained piece of a system with clearly defined linkages

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

Connector

A

A linkage between components with an interface

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

Common architectural styles

A 
client-server
peer-to-peer
publish-subscribe
repositories
pipe and filter
layering
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

client-server

A

server - component that provides services

client - component that interacts with the user and calls server

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

peer to peer

A

peer - component that provides services and may signal other peers

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

publish - subscribe

A

publish - when a component advertises it can send certain events
subscribe - when a component registers to receive certain events

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

repositories

A

client-server design provided storages for storing/accessing data

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

pipe and filter

A

filter - component that transforms data

pipe - connector that passes data between filters

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

layering

A

layer - components that can provide service to the next layer. Components hide lower levels

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

decomposition

A

taking application and breaking it down into smaller components. Layered architecture is really easy to decompose.

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

approaches for decomposing an architecture

A
  1. Functional decomposition
  2. Data-oriented decomposition
  3. Object-oriented decomposition
  4. Process oriented decomposition
  5. Feature-oriented decomposition
  6. Event-oriented decomposition
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Functional decomposition

A

break each requirement into function and then into sub-functions.

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

Data-oriented decomposition

A

Identify data structures in requirements. Break down recursively. Each data structure contains part of the data.

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

Object oriented decomposition

A

Essentially the same as functional aligned with data-oriented.

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

Process-oriented

A

Each subset completes one part of a task. IE: Authenticate user, display data, store results

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

Feature-oriented

A

Each feature makes the service a little better.

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

Event-oriented decomposition

A

Each component is broken into states such as clicking the mouse down and clicking the mouse up.

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

4 basic ways to evaluate architecture design

A
  1. Compare against desired quality models
  2. Check for problematic failure modes
  3. Walk through use-cases
  4. verify conformance to checklist of principles
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Quality attributes

A
  1. Maintainability
    - How hard will it be to make required changes
  2. Efficiency
    - Can the system respond quickly?
  3. Reliability
    - Will it perform under assumed conditions
  4. Integrity
    - Is it possible to put the system into a bad state
  5. Usability
    - Can real users interact with the system
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Error

A

Discrepancy between intended behavior and actual behavior

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

Fault

A

Defect in the system. My or may not lead to failure

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

Failure

A

Undesirable event caused by fault

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

Coupling

A

When one module is involved in another modules concern. Reduced maintainability

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

Cohesion

A

When a module is devoted to its concern. Increases maintainability.

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

Levels of coupling

A
  1. Content coupling(worst)
    - A modifies B
  2. Common coupling
    - A and B both modify the same data
  3. Control coupling
    - A calls B
  4. Stamp coupling
    - A provides structured data to B
  5. Data coupling
    - A provides unstructured data to B
  6. Uncoupled (best)
    - No coupling
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Levels of cohesion

A
  1. Functional/informational cohesion(best)
    - A and B work together for just one purpose
  2. Communicational cohesion
    - A and B use the same data
  3. Procedural cohesion
    - A executes, then B executes, and A and B have vaguely related purpose
  4. Temporal cohesion
    - A executes, then B executes, but A and B have no related purpose
  5. Logical cohesion
    - Either A or B might be executed
  6. Coincidental cohesion(worst)
    - None of the above
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Incremental development

A

When much of the systems values resides in one subsection
When one part of the system must be completed logically before another
IE: security systems

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

Iterative development

A

When a systems value is spread across much of the system

When the whole system needs to work at least a bit before you can build it up

44
Q

Types of design patterns

A 
Builder
Adapter
Facade
Memento
Interpreter
Observer
Template
45
Q

Builder

A

Knows how to create a complex object. Use when instantiating an object that requires an otherwise lengthy build process.

46
Q

Adapter

A

Translates one interface to another by wrapping. Use to overcome compatibility issues

47
Q

Facade

A

Object that provides a unified, high-level interface to a subsystem. Use when calling a subsystem requires a frequent series of complex lines of code.

48
Q

Memento

A

Encapsulate state in an object

Use if you might want to return to a certain state later

49
Q

Interpreter

A

Parses and acts on instructions written in a certain syntax. Use to add scriptability

50
Q

Observer

A

Watching for another object to change state
Maintains a list of observers and notifies them
Use in any event driven design

51
Q

Template

A

Breaks an algorithm into steps

Children inherit and override any steps they need to take

52
Q

Factory

A

Define an interface for creating an object, but let the classes that implement the interface decide which class to instantiate. The factory method lets a class defer instantiation to a subclass.

53
Q

Strategy

A

Allows for the selection of algorithm at runtime

54
Q

Decorator

A

useful for assigning behavior at runtime independently of other instances of the same class

55
Q

Composite

A

Allows for the reduction of complexity by dealing with a group of objects as a single object

56
Q

Visitor

A

Allows for a separation of the algorithm and the data it works on
Built on method overloading and dynamic types

57
Q

Good choice for small systems whose requirements can be fully understood before coding

A

waterfall

58
Q

Often a good choice for larger systems with many vague requirements and many alternatives for design and coding

A

spiral

59
Q

Often a good choice for systems where you can rapidly create something small but useful and then expand from there

A

agile

60
Q

Agile

A 
Iterative development
Timing:
- Sprint 1 month
- XP 1-2 weeks
Grouping: iterations can be grouped into releases
61
Q

DSDM

A

Agile development method

62
Q

Waterfall method pros & cons

A

Pros: Simplicity, traceability
Weakness: Requirements/design mistakes can be costly
Style: Highly controlled, high ceremony
“ceremony”- mow much planning, documentation is involved

63
Q

Spiral method pros & cons

A

Pros: Risk management, exploring alternatives
Weakness: Exploring alternatives can be costly
Style: Moderately controlled, moderate ceremony

64
Q

Agile method pros & cons

A

Pros: Flexibility
Weakness: Continual rework can be costly
Style: Rapid and organic, low ceremony

65
Q

Principles of XP

A
  • Communica:on
  • Simplicity
    • Feedback
  • Courage
66
Q

XP customer work flow

A
  1. Customers and Engineers: Collect user stories
  2. Engineers: Identify tasks
  3. Engineers: estimate effort
  4. Customers: prioritize stories
  5. Engineers plan work
  6. Engineers: communicate progress
  7. Customers and engineers: Evaluate results
67
Q

User story principles

A
  1. Not written in stone
  2. Fuzzy
  3. Minimalist
  4. Backed by acceptance tests
68
Q

User story

A

Name + short description.
EG: View eco-­‐friendliness.
The e-­‐commerce website users can click on a product and view its eco-­‐friendliness ratings.

69
Q

User stories: how to collect

A 
Start from starting point
Let customer walk through vision
Chunk the vision into user stories
Ask questions to clarify
Systematically break down each user story into pieces of work that will be required
70
Q

Effort estimates

A

All estimates done in nebulous unit that is at the discretion of the engineer
Based on experiences
Measures difficulty

71
Q

Effort estimate principles

A

Effort estimates are honest
Reliable
Based on each story individually

72
Q

Spikes

A

Small program or code that explores and tests possible solutions

73
Q

Extreme programming offers 3 ways to identify your goal

A
  1. User stories
  2. Acceptance tests
  3. Unit tests
74
Q

Who prioritizes user stories

A

The customer

75
Q

Key practices of DSDM

A 
Ambassador users and facilitated workshops
- Users on call and users en masse
Process:
1. Kick around ideas
2. Explore if Ideas are doable
3. Explore if ideas are worth doing
4. Give "Timebox" of work
5. Post project - what went well what didn't
76
Q

Principles of XP

A
  1. Communication
  2. Simplicity
  3. Feedback
  4. Courage
    Customer participates in tests
77
Q

Who do they learn from DSDM vs XP

A

Learn from:

  • XP: Customers
  • DSDM: Users
78
Q

What is the design based on DSDM vs XP

A

Design based on:

  • DSDM: Business values
  • XP: Customer direction
79
Q

What should the requirements vs DSDM vs XP

A

Requirements should be:

  • DSDM: High level
  • XP: Succinct
80
Q

What should the engineers demonstrate DSDM vs XP

A

Engineers must demonstrate

  • DSDM: Empowerment
  • XP: Courage
81
Q

Requirements validation vs verification

A

validation: Did they build the right system? does it do what it need
Verification: Did they build the system correctly? Does it do it HOW it needs

82
Q

Throwaway prototypes

A

Sketches on a piece of paper
Strength: Evaluating visual requirements
Weakness: Often misses interactions between use cases

83
Q

low fidelity prototypes

A

Photoshop prototypes
Strength: Evaluating visual requirements
Weakness: A little expensive, need design skills

84
Q

Stakeholder review

A

Sitting down with stakeholder
Strength: Evaluating fit to context
Weakness: Costs customer time

85
Q

Manual analysis

A

Going through design
Strength: Checking consistency
Weakness: Easy to miss errors

86
Q

Formal analysis

A

Going extensively through design
Strength: Can guarantee formally specifiable properties
Weakness: Expensive, need formal skills

87
Q

Acceptance test

A

Tests the system against the requirements provided by client

88
Q

Personal Software Process(PSP)

A
  • Record size of component
  • Record time taken
  • Refer to this data when making future predictions
89
Q

COCOMO

A

Effort estimation model

  • Access system complexity
  • Compute # of application points
  • Access teams productivity
  • Compute the effort
90
Q

Activity graph

A

Filed circles for start and finish
One circle for each milestone
Labeled arrows indicate activities

91
Q

CBR machine learning estimation model

A

Uses application points to estimate effort

92
Q

CASE

A

computer aided software engineering EG: testing software, etc.

93
Q

3GL components

A

reusable programmatic component you can reuse

94
Q

Critical path

A

Longest route through activity graph

95
Q

Slack time

A

Earlier possible start time, latest possible start time

96
Q

Activities on critical path have ___ path time

A

0

97
Q

Gantt chart

A

One bar per activity
Activities are diamonds
Arrows show dependencies

98
Q

Bad smell

A

Long methods
Duplicate code
Large classes
Long parameter lists

99
Q

Black box testing

A

Sends program stream of inputs, observes the outputs

Does not look at source code

100
Q

White box testing

A

Uses source code to design test cases

101
Q

Unit testing

A

Individual module testing

102
Q

Integration testing

A

How models work together testing

103
Q

System testing

A

Tries to break the system

104
Q

Acceptance testing

A

Used to see if the program meets requirements

105
Q

Regression testing

A

Check for old bugs in new changes

CS 361 (1 decks)

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