Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

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
decomposition
taking application and breaking it down into smaller components. Layered architecture is really easy to decompose.
26
approaches for decomposing an architecture
1. Functional decomposition 2. Data-oriented decomposition 3. Object-oriented decomposition 4. Process oriented decomposition 5. Feature-oriented decomposition 6. Event-oriented decomposition
27
Functional decomposition
break each requirement into function and then into sub-functions.
28
Data-oriented decomposition
Identify data structures in requirements. Break down recursively. Each data structure contains part of the data.
29
Object oriented decomposition
Essentially the same as functional aligned with data-oriented.
30
Process-oriented
Each subset completes one part of a task. IE: Authenticate user, display data, store results
31
Feature-oriented
Each feature makes the service a little better.
32
Event-oriented decomposition
Each component is broken into states such as clicking the mouse down and clicking the mouse up.
33
4 basic ways to evaluate architecture design
1. Compare against desired quality models 2. Check for problematic failure modes 3. Walk through use-cases 4. verify conformance to checklist of principles
34
Quality attributes
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
35
Error
Discrepancy between intended behavior and actual behavior
36
Fault
Defect in the system. My or may not lead to failure
37
Failure
Undesirable event caused by fault
38
Coupling
When one module is involved in another modules concern. Reduced maintainability
39
Cohesion
When a module is devoted to its concern. Increases maintainability.
40
Levels of coupling
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
41
Levels of cohesion
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
42
Incremental development
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
43
Iterative development
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
Types of design patterns
``` Builder Adapter Facade Memento Interpreter Observer Template ```
45
Builder
Knows how to create a complex object. Use when instantiating an object that requires an otherwise lengthy build process.
46
Adapter
Translates one interface to another by wrapping. Use to overcome compatibility issues
47
Facade
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
Memento
Encapsulate state in an object | Use if you might want to return to a certain state later
49
Interpreter
Parses and acts on instructions written in a certain syntax. Use to add scriptability
50
Observer
Watching for another object to change state Maintains a list of observers and notifies them Use in any event driven design
51
Template
Breaks an algorithm into steps | Children inherit and override any steps they need to take
52
Factory
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
Strategy
Allows for the selection of algorithm at runtime
54
Decorator
useful for assigning behavior at runtime independently of other instances of the same class
55
Composite
Allows for the reduction of complexity by dealing with a group of objects as a single object
56
Visitor
Allows for a separation of the algorithm and the data it works on Built on method overloading and dynamic types
57
Good choice for small systems whose requirements can be fully understood before coding
waterfall
58
Often a good choice for larger systems with many vague requirements and many alternatives for design and coding
spiral
59
Often a good choice for systems where you can rapidly create something small but useful and then expand from there
agile
60
Agile
``` Iterative development Timing: - Sprint 1 month - XP 1-2 weeks Grouping: iterations can be grouped into releases ```
61
DSDM
Agile development method
62
Waterfall method pros & cons
Pros: Simplicity, traceability Weakness: Requirements/design mistakes can be costly Style: Highly controlled, high ceremony "ceremony"- mow much planning, documentation is involved
63
Spiral method pros & cons
Pros: Risk management, exploring alternatives Weakness: Exploring alternatives can be costly Style: Moderately controlled, moderate ceremony
64
Agile method pros & cons
Pros: Flexibility Weakness: Continual rework can be costly Style: Rapid and organic, low ceremony
65
Principles of XP
* Communica:on * Simplicity * Feedback * Courage
66
XP customer work flow
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
User story principles
1. Not written in stone 2. Fuzzy 3. Minimalist 4. Backed by acceptance tests
68
User story
Name + short description. EG: View eco-­‐friendliness. The e-­‐commerce website users can click on a product and view its eco-­‐friendliness ratings.
69
User stories: how to collect
``` 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
Effort estimates
All estimates done in nebulous unit that is at the discretion of the engineer Based on experiences Measures difficulty
71
Effort estimate principles
Effort estimates are honest Reliable Based on each story individually
72
Spikes
Small program or code that explores and tests possible solutions
73
Extreme programming offers 3 ways to identify your goal
1. User stories 2. Acceptance tests 3. Unit tests
74
Who prioritizes user stories
The customer
75
Key practices of DSDM
``` 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
Principles of XP
1. Communication 2. Simplicity 3. Feedback 4. Courage Customer participates in tests
77
Who do they learn from DSDM vs XP
Learn from: - XP: Customers - DSDM: Users
78
What is the design based on DSDM vs XP
Design based on: - DSDM: Business values - XP: Customer direction
79
What should the requirements vs DSDM vs XP
Requirements should be: - DSDM: High level - XP: Succinct
80
What should the engineers demonstrate DSDM vs XP
Engineers must demonstrate - DSDM: Empowerment - XP: Courage
81
Requirements validation vs verification
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
Throwaway prototypes
Sketches on a piece of paper Strength: Evaluating visual requirements Weakness: Often misses interactions between use cases
83
low fidelity prototypes
Photoshop prototypes Strength: Evaluating visual requirements Weakness: A little expensive, need design skills
84
Stakeholder review
Sitting down with stakeholder Strength: Evaluating fit to context Weakness: Costs customer time
85
Manual analysis
Going through design Strength: Checking consistency Weakness: Easy to miss errors
86
Formal analysis
Going extensively through design Strength: Can guarantee formally specifiable properties Weakness: Expensive, need formal skills
87
Acceptance test
Tests the system against the requirements provided by client
88
Personal Software Process(PSP)
- Record size of component - Record time taken - Refer to this data when making future predictions
89
COCOMO
Effort estimation model - Access system complexity - Compute # of application points - Access teams productivity - Compute the effort
90
Activity graph
Filed circles for start and finish One circle for each milestone Labeled arrows indicate activities
91
CBR machine learning estimation model
Uses application points to estimate effort
92
CASE
computer aided software engineering EG: testing software, etc.
93
3GL components
reusable programmatic component you can reuse
94
Critical path
Longest route through activity graph
95
Slack time
Earlier possible start time, latest possible start time
96
Activities on critical path have ___ path time
0
97
Gantt chart
One bar per activity Activities are diamonds Arrows show dependencies
98
Bad smell
Long methods Duplicate code Large classes Long parameter lists
99
Black box testing
Sends program stream of inputs, observes the outputs | Does not look at source code
100
White box testing
Uses source code to design test cases
101
Unit testing
Individual module testing
102
Integration testing
How models work together testing
103
System testing
Tries to break the system
104
Acceptance testing
Used to see if the program meets requirements
105
Regression testing
Check for old bugs in new changes

CS 361 (1 decks)

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