Midterm Flashcards
(137 cards)
1
Q
Why do we write software?
A
We write software to solve problems
2
Q
What is essential complexity?
A
Essential difficulties are that are intrinsic to developing software.
These difficulties cannot be separated from the software development process.
3
Q
What is accidental complexity?
A
Accidental difficulties emerge because of circumstance
4
Q
What’s the “hard part” of writing software
A
Learning a new skill is hard.
The only way to get better, faster, and more efficient, is practice.
5
Q
External Software Quality - what is it and what are the measures?
A
Refers to the quality of the software from the perspective of the stakeholders
Functionality, Reliability, Usability, Efficiency, Portability
6
Q
Internal Software Quality - what is it and what are the measures?
A
Concerned with the software quality from the perspective of the developers
Primary - Maintainability
Within that: Analyzability, Changeability, Stability, Reusability, and Testability
7
Q
what is the most important skill to achieving high internal software quality?
A
design
8
Q
What is Compiling?
A
Compiling is turning human-readable source code into computer readable instructions
9
Q
What is Interpreting?
A
Fundamentally the same idea as compiling, only rather than turning the entire program into machine code first, and then running second, when code is interpreted, we do both at the same time with the help of another program
10
Q
How does Java work?
A
A programmer edits the .java file, then the .java files goes to the JDK to get compiled, which creates a .class file, which the JRE runs, and the JVM and JIT within the JRE interact with the actual computer to run the .class file
11
Q
What is JDK?
A
Java Development Kit
Compiles code and produces a .class file, which is the bytecode that specifies the machine instructions
12
Q
What is JRE?
A
Java Runtime Environment
Used to run Java programs
13
Q
What is JVM?
A
Java Virtual Machine
JVM is actually an interpreter, that interprets the code it is given at runtime, which is the .class bytecode compiled by the JDK, and passed to the JVM by the JRE; JVM handles the direct interactions with the actual underlying hardware
14
Q
What is JIT?
A
Just In Time Compiler
JIT is part of the JVM, specifically the part that can compile JVM bytecode instructions into machine code instructions for the underlying hardware
15
Q
What is a distributed repository?
A
There is a remote repository, and you work on your working copy, commit to your local repository, and then push to the remote repository
16
Q
What are the steps for merging?
A
- Commit your changes in your feature branch
- Checkout main
- Pull main
- Checkout feature branch
- git merge main to merge main into your feature branch
- Resolve any conflicts, commit and push
- Checkout main
- git merge featureBranch
17
Q
How do you use branches effectively and safely?
A
One branch per feature
18
Q
What are the advantages of Gradle?
A
- Greatly simplifies the process of downloading and using external libraries
- Greatly simplifies the process of updating to new libraries
- Greatly simplifies the process of building a Java project into a distributable Jar file
19
Q
What does the dependencies section in Gradle do?
A
Dependencies section lists all the external libraries the program is using
20
Q
What does the repositories section do in Gradle?
A
Repositories section tells Gradle that you want to download all references from the repository within the brackets
21
Q
What does the Gradle build command do? “gradle build”
A
The gradle build command is used to compile, test, and package your project; uses the globally installed version of Gradle
22
Q
What does Gradle’s test command do?
A
This tells gradle how to execute our tests
23
Q
What is the meaning of a fat-jar
A
It is a jar that contains not only my own code, but also all of the dependencies of my code
24
Q
Gradle wrapper (gradlew) - what does it do? Why is it useful?
A
./gradlew build: Uses the Gradle Wrapper, which ensures consistency by downloading and using the project-specific Gradle version
25
What question does verification ask?
Does our code meet our specification?
26
What question does validation ask?
Is the customer satisfied with our product?
27
Which V is internal and which is external?
Verification - Internal
Validation - External
28
Defect
an existing problem according to the software specification in the product that has not been discovered yet
29
Failure
the inability of the software system to perform its function according to the specification
30
Mistake
a human error that produces something incorrect, such as a bug in the code or a misunderstood customer need
31
Error
the difference between the current state and the correct state
32
What is the primary purpose of testing?
To find defects
33
True or False. Testing code can prove your code is bug free.
False
34
@Test
Used to identify a test-method
Methods must meet the following conditions:
- Must be public and NOT static
- Must return void
- Must take in no arguments
35
@BeforeEach
Tag tells JUnit to run the function before each test
Ensures that the state of the instance variable is always the same at the start of every test, no matter what tests we’ve run, or how many of them we have run
36
assertEquals
Testing scenario passes if the expected output and the actual output match
Always put the expected value first and the actual value second
37
How do you use assertEquals with doubles?
When comparing double variables, we want to use: assertEquals(double expected, double actual, double tolerance)
38
How do you use assertEquals with Objects?
Uses the .equals() method of the class of expected to compare to actual
39
assertThrows
Used when we expect the code we are using to throw an exception
Ex: assertThrows(IndexOutOfBoundsException.class, () -> myList.get(0));
40
Should you test the interface or the implementation?
Interface
41
What is a sound test?
A sound test is one that correctly tests against the specification
42
What is a false positive?
a test fails, indicating a defect, but there is no defect with the code
43
What is a false negative?
a test passes, but it shouldn’t, as there is an underlying defect that the test fails to find
44
Equivalence Tests
“Typical” test cases - test cases that show how the software behaves under normal, predictable conditions
45
Boundary Tests
Typically cases where there is something interesting or unique about the test case to separate it from an equivalence case
46
Exception Tests
Test cases that cannot be meaningfully executed correctly and should throw exceptions
47
Robustness Tests
Test cases that are syntactically valid but semantically meaningless; Often times in these cases, it may be unclear how they are intended to behave, and it may be worth checking the specification itself
48
Black-Box Testing
The tester focuses on the functionality of the software without any knowledge of its internal workings or code
49
What is equivalence partioning?
Breaking up our equivalence cases into groups that largely behave the same
50
White-Box Testing
The tester has full knowledge of the internal workings, structure, and code of the system
The tester exampines the code and creates test cases based on its logic, internal paths, and flows
Aims to achieve high code coverage
51
Statement Coverage
Measure of what percentage of statements have been covered by our tests
100% statement coverage is a good minimum target for testing, as we don’t want to rely on any lines of code we haven’t tested at least once
52
Branch Coverage
We want to write tests such that we test the outcome of all conditional logic
53
Conditonal Coverage
For every boolean value, we want to evaluate the code if it’s true or false
54
Path Coverage
We are interested in what percentage of possible paths through our code we have taken
54
Test-Driven Development
Write tests first that describe the specification first, and only implement the method after the code is written
TDD is inherently Black Box Testing
55
When should we use exceptions when designing?
to enforce pre-conditions and post-conditions of our function
56
When should you never throw and exception?
You should never throw exceptions along with try-catch as a way of handling control-flow
57
When to use try-catch
Should only be used when you can meaningfully handle an exception or when dealing with checked exceptions, turning a checked exception into an unchecked exception
Never catch an exception you can’t handle
58
Unchecked Exceptions
Exceptions that occur at runtime and are not checked by the compiler; handling is optional
59
Checked Exceptions
Exceptions that are checked at compile time; handling is not optional
60
assert [boolean_statement]
If the asserted statement is false, then this results in an AssertionError, which is not the same as an exception, and cannot be caught with a try-catch or Exception or any sub-types; Replace assert statements with Exceptions when deploying
61
Using defensive programming to ensure class is used correctly
- Want to make sure that if an exception was thrown, we don’t change the state of the object in question
- After testing assertThrows, test assertEquals to ensure that the state did not change
62
Analyzability
Core part of software internal quality -- maintainability
Readability - To what extent can we read and understand the code’s syntax
Understandability - To what extent can we read and understand the code’s semantics, or meaning and intent, of the code can be understood
63
What is the relationship between readability and understandability?
Readability is a necessary but insufficient condition for Understandability
Our code cannot be understandable if it isn’t readable; however, just because our code is readable does not mean it is understandable
64
What are some problems with internal quality of software to avoid
Long functions, large classes, long parameter list, boolean parameters, primitive obsessions, and message chains
65
Refactoring
the process of making changes to the code to improve the internal software quality, without making any changes to the functionality of the software
66
What are refactoring techniques?
Renaming identifiers, extract constants, abstract conditional logic, invert boolean, replace ErrorCode with Exception, replace Null with Optional, extract method, extract class, preserve whole object
67
What is DRY?
Don’t Repeat Yourself: avoiding duplication of code, logic, or data
68
What is WET?
Write Everything Twice: Suggests code duplication is sometimes acceptable, often when reuse would overcomplicate the code or reduce clarity
69
Lambda functions
A lambda function is an unnamed function; rather than naming a function, we create a function when it’s needed on the fly at runtime
70
What is the structure of a lambda function?
either (parameters) -> {code block} or (parameters) -> expression
71
What is Comparator used for?
sorted() and sort()
used in sorting lists, specifically Collections.sort(List list, Comparator comparator) and listInstance.sort(Comparator comparator); also used in defining TreeSets
72
What is Comparator's Method?
public int compare(E e1, E e2)
73
What is Consumer used for?
forEach()
take in some value and doing something with it, but don’t return anything; used specifically in Java’s foreach function on Collections, as well as foreach and peek in Streams
74
What is Consumer's Method?
public void accept(E e)
75
What is Predicate used for?
filter()
used for checking if a value meets some condition; specifically, it is used in the filter method for Streams
76
What is Predicate's method?
public boolean test(E e)
77
What is Function used for?
map()
pass some instance of T as an argument, return an instance of R; used in the map function in Java Streams
78
What is Function's method?
public R apply(T)
79
What is Executable used for?
assertThrows()
used in assertThrows, dynamicTest, and assumingThat
80
What is executable's method?
public void execute()
81
What are Java Streams?
A stream is like an assembly line – we take in some collection of information on one side, pass it through a number of steps, and then at the end we have some useful information
82
What can you make streams from?
List, Set, Map (via entrySet())
82
Intermediate Operations: map
Method: map(Function f)
Output: Stream
Explanation: used to convert our data from one thing to another
82
stream() vs parallelStream()
stream(): This gives us a Stream that we can now perform zero or more intermediate operations one (which will be the bulk of our logic), and one terminal option on, which converts the stream back into something useful like a List, or gives us summary information (such as an integer sum)
parallelStream(): We can replace stream() with parallelStream() to take advantage of automated multithreading
82
What is the cost of multithreading?
May do operations in an unpredictable order
83
Intermediate Operations: filter
Method: filter(Predicate p)
Output: Stream with only elements that return true for our Predicate function; elements that return false are removed from the Stream
Explanation: we may want to “filter out” certain values from our stream, or only keep certain other values
83
Intermediate Operations: sorted example
.sorted((a, b) -> a.size() - b.size())
83
Intermediate Operations: sorted
Method: sorted(Comparator comparator)
Output: Stream sorted by the comparator
Explanation: we may want to sort during our intermediate steps (such as when we get the five smallest states); this method lets us define a sorting methodology functionally
83
Intermediate Operations: peek
Method: peek(Consumer e)
Output: Stream with no elements removed or altered (unless altered as a side effect of the Consumer function in peek)
Explanation: similar to forEach, this method performs some functions on every element in the Stream; however, forEach is a terminal operation, while peek is an intermediate operation
84
Intermediate Operations: map example
.map(x -> x.size())
84
Intermediate Operations: peek example
.peek(System.out::println)
84
Intermediate Operations: limit example
.limit(10)
84
Intermediate Operations: filter example
.filter(x -> x.getPopulation > 1000000)
84
Intermediate Operations: limit
Method: limit(long n)
Output: Stream, but only the first n elements
Explanation: in general, if we want to use limit, we only use it after sorted
85
Intermediate Operations: distinct
Method: distinct()
Output: Stream with all duplicate elements removed
Explanation: uses E’s .equals() method to remove any duplicate elements from our Stream
86
Terminal Operations: forEach
Method: forEach(Consumer e)
Output: void – forEach cannot be used to return anything directly
Explanation: used for performing some action with items left in the Stream at the end of the intermediate operations
86
Intermediate Operations: distinct example
.distinct()
87
Terminal Operations: forEach example
names.stream().forEach(name -> System.out.println(name));
88
Terminal Operations: count
Method: count()
Output: long – the number of items left in the Stream
89
Terminal Operations: count example
.count()
90
Terminal Operations: toList example
List evenNumbers = numbers.stream().filter(n -> n % 2 == 0).collect(Collectors.toList());
90
Terminal Operations: toList
Collectors.toList() returns a List which matches the state of the Stream at the end of the Stream chain of operations
91
Terminal Operations: reduce
reduce allows you to define a way to reduce a stream of multiple objects to one value
92
Terminal Operations: reduce example
int totalPopulation = stateList.stream().map(State::getPopulation).reduce(0, (subtaotal, statePopulation) -> subtotal + statepopulation);
93
How do we tell the difference between a good design and a bad design?
A good software design is modular, maintainable, scalable, flexible, and simple, with a clear structure that facilitates testing and future changes
A bad software design is often rigid, difficult to maintain, and prone to errors, with tightly coupled components, poor scalability, and convoluted logic
94
Modularity
Break up our big problem into little problems that are easier to solve, and each unit is potentially reusable
94
Functional Independence
Each module can perform its own purpose with minimal interactions with the rest of the system
Gold standard – when two modules only interact through passing arguments and receiving return values via public functions
95
What do we want modules to be?
highly cohesive and loosely coupled
96
Abstraction
the process of hiding all unnecessary details and exposing only required details
97
What does it mean to design for the interface, not the implementation?
So long as the interface is maintained, changes to the implementation will not force changes to other modules
98
Information Hiding
Mechanism by which we create a limited interface to achieve abstraction
99
What does "highly cohesive" mean, and why is it desirable?
Highly cohesive refers to the degree to which the elements within a module, class, or component of a software system are closely related and focused on a single, well-defined task
Means that the methods, functions, and responsibilities inside a class or module all contribute to performing a unified and specific function
100
Why is abstraction good?
It encourages focusing on the abstractions (interfaces) that define the behavior of a system rather than the specific implementation details
This leads to more flexible, maintainable, and scalable systems
101
What does "loosely coupled" mean, and why is it desirable?
Loosely coupled refers to the degree of dependency between components, classes, or modules in a software system
In a loosely coupled system, components have minimal dependencies on each other, meaning changes in one component are less likely to affect other components
Each module or class interacts with others through well-defined interfaces, rather than relying on direct knowledge of their inner workings or implementation details
102
Coincidental Cohesion
Worst – very loose cohesion, avoid at all costs
Elements are combined into a module by effectively coincidence
103
Logical Cohesion
Worst – very loose cohesion, avoid at all costs
Elements are grouped into a module because they described the same general activity, or have similar interfaces, or are otherwise categorized the same
103
Temporal Cohesion
Worst – very loose cohesion, avoid at all costs
Where items are grouped because they occur at or around the same time (but not in any particular sequence), but are otherwise unrelated
104
Procedural Cohesion
Decent – acceptable, but often could be better
Supporting unrelated activities in which control passes from one activity to the next, ensuring they execute in a specific order
105
Communicational Cohesion
Decent – acceptable, but often could be better
Elements are grouped together in a module simply because they perform actions on the same data for either input or output
106
Sequential Cohesion
Best
Generally considered very cohesive, second only to functional
We can group modules into individual “procedures”
107
Functional Cohesion
Best
Describes a single well-supported function, i.e., a something that only does one thing
Module only has one behavior
This is very maintainable, because so long as the interface remains the same, the implementation can change without propagating change to any other module
108
Content Coupling
Occurs when one class modifies the inner state of a class it depends on directly instead of using the public interface
109
Common Coupling
When they have read and write access to the same global data
110
Control Coupling
When one module passes some kind of flag (typically a boolean) to another module which is used in control flow
111
Stamp Coupling
Exists when a module passes a data structure to another module, when the entire data structure is not needed
112
Data Coupling
The gold standard: all communication between modules is done via passing the minimum amount of data as arguments and returning exactly the data needed
This insures that any action taken by the “called” method, with the exception the data it returns, will not affect the execution of the calling method
113
Dependency
A class depends on another class when it uses methods or functions from that class
114
Aggregation/Composition
Aggregation “A aggregates B” - refers to an instance of class, A, “has” one or more instances of Class B
Composition - “A is composed of B” refers to a relationship where one or more instances of B are intrinsically part of another class, A. In general, B does not such that they often cannot be meaningfully seperated. The composing class brings together these items, and the items by themselves don’t have a meaning outside of their attachment to the composing class. Composition relationships are a subset of Aggregation relationships
115
Bidirectional Association, specifically in the form of mutual Aggregation
Two classes are connected in such a way that interaction may be needed both ways
In general, with bidirectional associations, the semantics generally refer to a relatively symmetrical relationship in the sense that neither class possesses the other, but they do reference each other
116
Realization (implementing interfaces)
A class realizes an interface or abstract by implementing/extending it
"is-a" relationship
117
Generalization (extending classes) aka Inheritance
a parent describes a general behavior, and a child describes a specific behavior, or specialization of the parent
Generalization encapsulates all “is-a” relationships
118
Why do we often say "Prefer Composition/Aggregation over Inheritance"?
Specifically, what is the flaw in Inheritance?
Introducing abstraction to support polymorphism is valuable when it reduces usage complexity by more than it increases coupling and implementation complexity
Creates a tight coupling:
1) The caller is coupled to the abstraction as either an aggregation or a dependency
2) Any implementators are coupled to the abstraction in a realization way
119
Single Responsibility Principles
Each software should have one, and only one, reason to change
120
Different between implementing interface and extending classes
Inheritance in Java is when a class (child) inherits the properties and methods of another class (parent)
A class can implement multiple interfaces, but can extend only one parent class
Inheritance means it must implement all methods declared in the interface, but extends means it inherits methods from the parent class (can override or add new ones)
121
Benefit of Polymorphism
Polymorphism enables the ability to "call the same method" on different types of objects and have each object respond in its own way
122
Dependency Inversion
Entities should only depend on abstractions, not on concretions
It suggests that high-level modules should not depend on low-level modules; both should depend on abstractions (such as interfaces or abstract classes)
Abstractions should not depend on details, but details should depend on abstractions
