1/185
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced |
---|
No study sessions yet.
Software Object
A programming construct that encapsulates data (attributes/state) and behavior (methods) into a single, self-contained unit.
Method (Operation)
A callable procedure defined inside an object that specifies an acceptable service the object can perform.
Method Signature
The name of a method together with its parameters, parameter types, and return type; defines how clients may call the method.
Interface
A set of method signatures that describes the services an object offers while hiding its internal state.
Encapsulation
The principle of hiding an object’s internal state and exposing functionality only through its interface.
Client Object
An object that sends messages (method calls) requesting services from other objects.
Server Object
An object that receives messages, performs requested services, and returns results.
Message
A method call sent from a client object to a server object to request a service.
On-Demand Design
Design approach where interfaces and their implementations are created to satisfy the immediate needs of client objects rather than pre-defining features.
Attributes (State)
Variables maintained inside an object that represent its current condition or data.
Software Module
A loose grouping of subprograms and data; lacks the strict encapsulation enforced by objects.
Subprogram (Behavior)
A standalone procedure or function inside a module; equivalent to a method inside an object.
Composition
An object relationship in which one object contains references to other objects to use their services (has-a relationship).
Inheritance
An object relationship where a derived class acquires the attributes and methods of a base class (is-a relationship).
Change Propagation
The effect where modifications in a base class automatically affect derived classes, creating potential risk for new bugs.
UML Class Notation
A diagram element with three compartments: class name, attributes, and operations.
UML Interface
A stereotype «interface» element that lists only operation signatures, implemented by one or more classes.
Base Class
A general class whose properties are inherited by another class.
Derived Class
A class that extends a base class, inheriting and possibly overriding its behavior.
Front-End Class
In composition, the object that acts as a façade, delegating work to the contained (back-end) object.
Process-Oriented Approach
Development mindset centered on sequential steps and actions; intuitive but hard to scale for complex systems.
Object-Oriented Approach
Development mindset centered on organizing responsibilities among collaborating objects; scales better but is harder to design well.
Traceability
The ability to follow every requirement through design, implementation, and testing artifacts without unexplained gaps.
Test-Driven Development (TDD)
A practice where tests are written first and development proceeds only when code passes those tests.
Measurement (in SE)
The use of metrics and tools to monitor product quality and developer productivity.
Security Development Lifecycle (SDL)
Microsoft’s structured process for integrating security considerations throughout software development.
Prime Factorization
The expression of an integer as a product of prime numbers (e.g., 905 = 5 × 181).
Coprime (Relatively Prime)
Two integers with no common factor other than 1; equivalently, their greatest common divisor is 1.
Greatest Common Divisor (GCD)
The largest integer that divides two numbers without remainder; equals 1 for coprime pairs.
Rube Goldberg Machine (TDD Example)
Illustrates that passing a single test case doesn’t guarantee robustness; a system may work for one scenario yet remain fragile.
Object-Oriented Design (OOD)
A discipline focused on designing software that is easy to modify, extend and maintain by organizing systems around interacting objects.
Object-Oriented Programming (OOP)
A programming paradigm based on objects containing data and behavior; language support alone is insufficient without proper design practices.
SOLID
A mnemonic coined by Robert C. Martin summarizing five key principles—SRP, OCP, LSP, ISP, DIP—for managing dependencies and creating flexible, maintainable software.
Single Responsibility Principle (SRP)
States that a class should have only one reason to change, encouraging high cohesion and separation of concerns.
Cohesion
The functional relatedness of elements within a module; high cohesion means a module’s elements change for the same single reason.
Open/Closed Principle (OCP)
Classes, modules, or functions should be open for extension but closed for modification, allowing new behavior without altering existing code.
Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types without altering the correctness of a program, ensuring polymorphic behavior.
Interface Segregation Principle (ISP)
Clients should not be forced to depend on interfaces they do not use; many specific interfaces are better than one large, ‘fat’ interface.
Dependency Inversion Principle (DIP)
High-level and low-level modules should both depend on abstractions, not on concrete classes, thereby decoupling software layers.
Robert C. Martin ("Uncle Bob")
Software engineer and author who popularized the SOLID principles through books like “Clean Code” and “Agile Software Development.”
Structured Programming
An earlier methodology emphasizing control structures over GOTO statements; precursor to object-oriented approaches for building complex software.
Fat Interface
An interface that contains methods unrelated to a particular client’s needs, causing unnecessary coupling and violating ISP.
Abstraction (in DIP context)
A high-level definition (interface or abstract class) that both high-level and low-level modules depend upon, enabling flexibility and reuse.
Coupling
The degree to which one component relies on another; SOLID principles aim to minimize tight coupling and improve maintainability.
Reason to Change
A distinct cause that forces a class or module to be modified; SRP demands each class have exactly one such reason.
Coding Standards
Documented conventions that guide code formatting, naming, commenting, and banned constructs to ensure consistency across a project.
Characteristics of Good Implementation
Key qualities—readability, maintainability, performance, traceability, correctness, and completeness—that well-written code should possess.
Readability (Code)
The ease with which a human can understand the purpose, control flow, and data flow of source code.
Maintainability
How easily software can be modified to fix defects, improve performance, or adapt to a changed environment.
Performance (Software)
The efficiency with which a program uses resources such as CPU, memory, and I/O to perform its tasks.
Traceability
The ability to link code back to requirements, design documents, and test cases.
Correctness
The degree to which software adheres to specified functional requirements.
Completeness (Implementation)
Extent to which all required features are fully implemented in the software.
Naming Convention
A set of rules for choosing identifiers (classes, methods, variables, files) that promote clarity and consistency.
Global Identifier Naming Guideline
Use longer, descriptive names for globally visible identifiers; keep local names short.
Python lowerwithunder
Preferred Python style for functions, variables, modules, and packages (e.g., my_function).
CapWords (CamelCase)
Python recommendation for class and exception names (e.g., MyClass).
CAPSWITHUNDER
Python style for constants at module or class scope (e.g., MAX_SPEED).
GUI Prefix "btn"
Naming prefix indicating a button control, e.g., btnLogin.
GUI Prefix "chk"
Naming prefix indicating a checkbox control, e.g., chkStatus.
Function/Method Size Rule
Keep methods under ~50 lines to reduce error likelihood and simplify understanding.
File‐Naming Best Practice
Use short (<25 char), descriptive names without spaces or special characters; write conventions in a data-management plan.
ISO 8601 Date Format
YYYYMMDD representation recommended for embedding dates in file names (e.g., report_20241005.txt).
Avoid GOTO
Structured programming guideline that prohibits GOTO/setjmp/longjmp to preserve readable control flow.
Multiple Inheritance (Risk)
Discouraged practice because it can introduce ambiguity and complexity in object hierarchies.
Comment Smell: Code Repetition
Comment merely restates code and should be avoided.
Comment Type: Description of Intent
Most valuable comment; explains WHY the code exists, not what it literally does.
Coding Standards Repository
Central location (e.g., repo_standards/general.md) storing language-specific guidelines.
Debugging – Stabilization/Reproduction
Phase where a minimal test case that reliably triggers the defect is produced.
Debugging – Localization
Process of finding the exact code section responsible for a defect.
Debugging – Correction
Modifying code to eliminate the located defect.
Debugging – Verification
Confirming the fix and ensuring no regressions, often using tools like source comparators or interactive debuggers.
Source Code Comparator
Tool that highlights differences between code versions to aid verification (e.g., Code Compare).
Interactive Debugger
Tool that allows step-through execution, variable inspection, and breakpoint control during debugging.
Assertion
Executable statement that checks a condition assumed true; used for defensive programming.
Defensive Programming
Technique of writing code that anticipates and guards against possible errors or misuse.
Profiler
Performance tool that measures resource usage to guide optimization.
Refactoring
Improving code structure and readability without altering external behavior.
Code Smell
Surface indication that usually corresponds to a deeper problem (e.g., duplicated code, long methods).
Long Method (Smell)
Excessively lengthy routine; often refactored by extracting smaller functions.
Feature Envy (Smell)
Method that excessively uses data or methods of another class, suggesting a relocation of logic.
Three Golden Rules of UI Design
1) Place user in control, 2) Reduce user memory load, 3) Ensure consistency.
Place User in Control
UI principle where operations are reversible and users initiate actions rather than react to system behavior.
Reduce User’s Memory Load
Design guidance to minimize the amount of information users must remember by keeping cues visible.
Consistent User Interface
Maintaining uniform visual and interaction patterns across an application to enhance learnability.
Object-Oriented Design (OOD)
A design approach that models a system as a set of self-contained objects and object classes which manage their own state and operations.
Object
An entity with state (attributes) and behavior (operations) that provides services to other objects via message passing.
Object Class
A template that defines the attributes and operations common to a group of objects; used to instantiate objects.
Encapsulation
The principle of hiding an object's internal state and requiring all interaction to occur through its operations.
Message Passing
The mechanism by which objects communicate, conceptually sending a service request and any required data.
Object-Oriented Analysis (OOA)
The activity focused on building an object model of the application domain to understand requirements.
Object-Oriented Programming (OOP)
The implementation of an OOD using an object-oriented language such as Java or C++.
Advantages of OOD
Includes easier maintenance, better reusability, and natural mapping of real-world entities to system objects.
Unified Modeling Language (UML)
A standardized set of notations used to model object-oriented analysis, design, and implementation artifacts.
UML Structural Diagram
A diagram type that shows the static structure of a system, e.g., Class, Object, Component, Deployment diagrams.
UML Behavioral Diagram
A diagram type that depicts dynamic behavior, e.g., Sequence, State Machine, Activity diagrams.
Class Diagram
A UML structural diagram that depicts classes, their attributes, operations, and relationships.
Attribute
A named property of a class that describes the data held by its objects; appears in the second compartment of a class box.
Derived Attribute
An attribute whose value can be computed from other attributes, denoted with a preceding “/” in UML.
Operation
A function or service provided by a class; listed in the third compartment of a UML class box.