Software Engineering Concepts Quiz

Describes the system's actions and the outcome of those actions. For example, a system should allow users to log in.

Specifies constraints on the system's performance, security, usability, and other non-functional characteristics. For example, a system should have a response time of less than 1 second.

A technique used to identify and understand the needs of users and stakeholders. It can be used to gather information about the system requirements, including functional and non-functional requirements.

An actor is an entity that interacts with a system, such as a user, another system, or a device. A use case is a specific functionality or service provided by the system, such as logging in, searching for information. The relationship between an actor and a use case is represented by an association.

Shows the interaction between actors and use cases. It can also show relationships between use cases, such as 'include' and 'extend'.

The primary sequence of events in a use case. Alternative flows describe the possible sequences of events, including error conditions and exceptions. It provides a structured way to understand a use case and its variations.

The process of evaluating the quality of requirements to ensure that they are complete, consistent, feasible, and modifiable. It helps to identify flaws, such as omissions, contradictions, or infeasibility.

Involve stakeholders in the requirements process. Get feedback from users, subject matter experts, and other stakeholders to ensure that the requirements accurately reflect their needs. Also, be sure to update the requirements document as needed.

A technique for simplifying complex systems by focusing on the essential details while hiding the implementation details.

The degree of interdependence between different parts (modules) of a software system. High coupling means parts are heavily dependent on each other, while low coupling means they are more independent.

The degree to which a module focuses on a single, well-defined task. High cohesion means a module does one thing well, while low cohesion means a module does many things.

Breaking a large system into smaller, independent, reusable parts (modules).

A principle that states the structure of a software system reflects the structure of the team that created it. This means collaboration is KEY in architectural design!

A layered architecture where each layer provides services to the layer above. Think of a cake, each layer sits upon the one below.

An architecture where data is processed by a series of components (filters) that pass the output to the next component. Think of a factory assembly line.

A distributed architecture where clients request services from central servers. Think of a bank teller taking requests from customers.

A design pattern that enables accessing elements of a collection sequentially without revealing its inner workings.

A design pattern that defines a family of interchangeable algorithms. It encapsulates each algorithm and makes them replaceable.

The process of determining if a system or component meets specified requirements during or after development.

Ensuring that a specific phase of software development has been completed correctly.

Inputs designed to test software and compare results to expected outcomes.

Software testing that involves automated and repeated execution of test cases.

Software testing done manually without relying on automated tools.

A software defect or bug.

A discrepancy between the expected and actual output caused by a fault.

A diagram that shows the relationships between classes in a software system, including attributes, operations, and associations.

A representation of a problem or a system as it is, before any solution is implemented.

A design specification that defines the structure of the software system, outlining how it will be written.

The actual implementation of the software system, using concrete classes with attributes and operations.

A fundamental building block in a software system, consisting of attributes (data) and operations (actions), connected by relationships.

A connection between two classes, representing how they interact and depend on each other.

A type of association where one class is a part of the other, like a car containing an engine.

A specific form of aggregation where the parts cannot exist independently from the whole. If the whole is removed, the parts are destroyed.

A class that cannot be instantiated, but serves as a template for other classes.

A description of a set of behaviors that objects must implement.

A diagram that shows how objects in a system interact with each other in a specific scenario, over time.

Pre-built solutions to common software design problems. Reusable components that provide proven patterns for specific scenarios.

Testing based on the software's specifications, focusing on what the software should do without considering its internal structure.

Testing based on the internal structure of the software, aiming to test all logical paths within the code.

Dividing input domains into equivalence classes with similar behavior, simplifying testing by selecting representative inputs.

Testing at the boundaries of input and output ranges, often revealing errors missed by typical input values.

Ensuring every line of code is executed at least once, providing fundamental coverage of the code base.

Ensuring every possible path through the code is executed, testing all possible flows and branching decisions.

A metric used to measure the quality of test suites, assessing how effectively the code is tested.

Testing a sequence of method calls to ensure a complete behavior flow is working properly, testing interaction between different parts of the code.

JUnit's assertEquals method is used to compare the values of variables, often used to ensure that a method produces the expected output.

JUnit's assertThrows method is used to test if a specific exception is thrown when a method is executed. This helps ensure that the code handles errors as expected.

JUnit's assumeTrue and assumeFalse methods allow you to skip a test based on certain conditions. This helps to avoid running unnecessary tests and ensures the tests are efficient.

The TRAFFIC method is a structured approach for debugging. It involves tracking the problem, reproducing it, automating the process, finding the origin, focusing on relevant sections, isolating the error, and finally, correcting it.

A problem tracker is a tool used to manage bug reports. It tracks the lifecycle of a bug from its discovery to its resolution. It also includes information like expected behavior and the problem history.

Reproducibility is the ability to recreate an error consistently. Isolation pinpoints the specific conditions that trigger the error. Generalization identifies patterns in the error's occurrence. Summarization provides a concise description of the problem and its impact. Condensation simplifies the test case to its minimum size. Disambiguation differentiates the error from other similar issues. Neutralization eliminates irrelevant factors that might obscure the root cause.

Property-based testing involves identifying properties of the system under test, creating test cases that cover all combinations of property values, and using assumptions to filter out irrelevant test cases.

The Property-First Guideline suggests formulating specific properties of the system before directly classifying methods. This ensures that test cases are based on the desired behavior of the system.

A specific functionality or service provided by the system, such as logging in, searching for information.

The primary sequence of events in a use case.

Other possible sequences of events, including error conditions and exceptions.

Focus on object creation mechanisms, offering flexibility and reusability.

Deal with object composition and relationships, focusing on class and object structures

Address how objects interact and communicate, optimizing algorithms and responsibilities.

Defines a one-to-many dependency between objects, allowing for automatic notification and updates when one object changes state. This pattern involves a Subject that maintains a list of Observers and notifies them of changes.

Composes objects into tree structures, representing part-whole hierarchies, like a file system or GUI components. This pattern features a Component, Leaf, and Composite.

Defines a grammatical representation for a language and interprets sentences in that language. This pattern involves a Context, Abstract Expression, Terminal Expression, and Nonterminal Expression.

Separates an algorithm from the object structure on which it operates, enabling flexibility in applying algorithms to different structures. This pattern involves an Element and Visitor.

A technique for minimizing a failing test case to identify the source of the error. This helps pinpoint the root cause of a bug by removing irrelevant parts of the test input.

Statements that check the validity of a program's state at a specific point. They're like checkpoints to ensure things are working as expected.

A type of software maintenance that focuses on fixing defects or bugs that appear in the software.

A type of software maintenance that involves making changes to adapt the software to a new environment, like a new operating system or hardware.

A metric that measures the logical complexity of a code segment. It helps determine the number of possible paths through the code.

A structured approach to debugging involving tracking, reproducing, automating, finding, focusing, isolating, and correcting the error.

A tool used to manage bug reports. It tracks the lifecycle of a bug from discovery to resolution.

The ability to recreate an error consistently. It involves isolating the causes, generalizing patterns, summarizing the issue, condensing the test case, disambiguating it from other errors, and neutralizing irrelevant factors.

A type of code coverage that requires each possible branch in conditional statements to be executed at least once.

Measures the complexity of a class based on the number and complexity of its methods.

Assesses the depth of inheritance in a class hierarchy. A higher DIT means a longer chain of inheritance.

Counts the number of subclasses a class has. A higher NOC means more specializations and potentially more complexity.

Measures the degree of interdependence between classes. High CBO means classes are tightly coupled and changes in one can affect many others.

Determines the number of methods a class may potentially call. A higher RFC means a wider range of interactions and potentially more complex behavior.

Evaluates the degree to which methods within a class are related. Low LCOM means methods are scattered and unrelated, making the class less cohesive.

Restructuring code to improve its design and readability without altering its external behavior.

Indicators of potential design problems or areas that could benefit from refactoring.