cecs 343 final part 1

0.0(0)
studied byStudied by 0 people
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
Card Sorting

1/84

flashcard set

Earn XP

Description and Tags

implentation object model solid principles

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

85 Terms

1
New cards

Software Object

A programming construct that encapsulates data (attributes/state) and behavior (methods) into a single, self-contained unit.

2
New cards

Method (Operation)

A callable procedure defined inside an object that specifies an acceptable service the object can perform.

3
New cards

Method Signature

The name of a method together with its parameters, parameter types, and return type; defines how clients may call the method.

4
New cards

Interface

A set of method signatures that describes the services an object offers while hiding its internal state.

5
New cards

Encapsulation

The principle of hiding an object’s internal state and exposing functionality only through its interface.

6
New cards

Client Object

An object that sends messages (method calls) requesting services from other objects.

7
New cards

Server Object

An object that receives messages, performs requested services, and returns results.

8
New cards

Message

A method call sent from a client object to a server object to request a service.

9
New cards

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.

10
New cards

Attributes (State)

Variables maintained inside an object that represent its current condition or data.

11
New cards

Software Module

A loose grouping of subprograms and data; lacks the strict encapsulation enforced by objects.

12
New cards

Subprogram (Behavior)

A standalone procedure or function inside a module; equivalent to a method inside an object.

13
New cards

Composition

An object relationship in which one object contains references to other objects to use their services (has-a relationship).

14
New cards

Inheritance

An object relationship where a derived class acquires the attributes and methods of a base class (is-a relationship).

15
New cards

Change Propagation

The effect where modifications in a base class automatically affect derived classes, creating potential risk for new bugs.

16
New cards

UML Class Notation

A diagram element with three compartments: class name, attributes, and operations.

17
New cards

UML Interface

A stereotype «interface» element that lists only operation signatures, implemented by one or more classes.

18
New cards

Base Class

A general class whose properties are inherited by another class.

19
New cards

Derived Class

A class that extends a base class, inheriting and possibly overriding its behavior.

20
New cards

Front-End Class

In composition, the object that acts as a façade, delegating work to the contained (back-end) object.

21
New cards

Process-Oriented Approach

Development mindset centered on sequential steps and actions; intuitive but hard to scale for complex systems.

22
New cards

Object-Oriented Approach

Development mindset centered on organizing responsibilities among collaborating objects; scales better but is harder to design well.

23
New cards

Traceability

The ability to follow every requirement through design, implementation, and testing artifacts without unexplained gaps.

24
New cards

Test-Driven Development (TDD)

A practice where tests are written first and development proceeds only when code passes those tests.

25
New cards

Measurement (in SE)

The use of metrics and tools to monitor product quality and developer productivity.

26
New cards

Security Development Lifecycle (SDL)

Microsoft’s structured process for integrating security considerations throughout software development.

27
New cards

Prime Factorization

The expression of an integer as a product of prime numbers (e.g., 905 = 5 × 181).

28
New cards

Coprime (Relatively Prime)

Two integers with no common factor other than 1; equivalently, their greatest common divisor is 1.

29
New cards

Greatest Common Divisor (GCD)

The largest integer that divides two numbers without remainder; equals 1 for coprime pairs.

30
New cards

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.

31
New cards

Object-Oriented Design (OOD)

A discipline focused on designing software that is easy to modify, extend and maintain by organizing systems around interacting objects.

32
New cards

Object-Oriented Programming (OOP)

A programming paradigm based on objects containing data and behavior; language support alone is insufficient without proper design practices.

33
New cards

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.

34
New cards

Single Responsibility Principle (SRP)

States that a class should have only one reason to change, encouraging high cohesion and separation of concerns.

35
New cards

Cohesion

The functional relatedness of elements within a module; high cohesion means a module’s elements change for the same single reason.

36
New cards

Open/Closed Principle (OCP)

Classes, modules, or functions should be open for extension but closed for modification, allowing new behavior without altering existing code.

37
New cards

Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types without altering the correctness of a program, ensuring polymorphic behavior.

38
New cards

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.

39
New cards

Dependency Inversion Principle (DIP)

High-level and low-level modules should both depend on abstractions, not on concrete classes, thereby decoupling software layers.

40
New cards

Robert C. Martin ("Uncle Bob")

Software engineer and author who popularized the SOLID principles through books like “Clean Code” and “Agile Software Development.”

41
New cards

Structured Programming

An earlier methodology emphasizing control structures over GOTO statements; precursor to object-oriented approaches for building complex software.

42
New cards

Fat Interface

An interface that contains methods unrelated to a particular client’s needs, causing unnecessary coupling and violating ISP.

43
New cards

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.

44
New cards

Coupling

The degree to which one component relies on another; SOLID principles aim to minimize tight coupling and improve maintainability.

45
New cards

Reason to Change

A distinct cause that forces a class or module to be modified; SRP demands each class have exactly one such reason.

46
New cards

Coding Standards

Documented conventions that guide code formatting, naming, commenting, and banned constructs to ensure consistency across a project.

47
New cards

Characteristics of Good Implementation

Key qualities—readability, maintainability, performance, traceability, correctness, and completeness—that well-written code should possess.

48
New cards

Readability (Code)

The ease with which a human can understand the purpose, control flow, and data flow of source code.

49
New cards

Maintainability

How easily software can be modified to fix defects, improve performance, or adapt to a changed environment.

50
New cards

Performance (Software)

The efficiency with which a program uses resources such as CPU, memory, and I/O to perform its tasks.

51
New cards

Traceability

The ability to link code back to requirements, design documents, and test cases.

52
New cards

Correctness

The degree to which software adheres to specified functional requirements.

53
New cards

Completeness (Implementation)

Extent to which all required features are fully implemented in the software.

54
New cards

Naming Convention

A set of rules for choosing identifiers (classes, methods, variables, files) that promote clarity and consistency.

55
New cards

Global Identifier Naming Guideline

Use longer, descriptive names for globally visible identifiers; keep local names short.

56
New cards

Python lowerwithunder

Preferred Python style for functions, variables, modules, and packages (e.g., my_function).

57
New cards

CapWords (CamelCase)

Python recommendation for class and exception names (e.g., MyClass).

58
New cards

CAPSWITHUNDER

Python style for constants at module or class scope (e.g., MAX_SPEED).

59
New cards

GUI Prefix "btn"

Naming prefix indicating a button control, e.g., btnLogin.

60
New cards

GUI Prefix "chk"

Naming prefix indicating a checkbox control, e.g., chkStatus.

61
New cards

Function/Method Size Rule

Keep methods under ~50 lines to reduce error likelihood and simplify understanding.

62
New cards

File‐Naming Best Practice

Use short (<25 char), descriptive names without spaces or special characters; write conventions in a data-management plan.

63
New cards

ISO 8601 Date Format

YYYYMMDD representation recommended for embedding dates in file names (e.g., report_20241005.txt).

64
New cards

Avoid GOTO

Structured programming guideline that prohibits GOTO/setjmp/longjmp to preserve readable control flow.

65
New cards

Multiple Inheritance (Risk)

Discouraged practice because it can introduce ambiguity and complexity in object hierarchies.

66
New cards

Comment Smell: Code Repetition

Comment merely restates code and should be avoided.

67
New cards

Comment Type: Description of Intent

Most valuable comment; explains WHY the code exists, not what it literally does.

68
New cards

Coding Standards Repository

Central location (e.g., repo_standards/general.md) storing language-specific guidelines.

69
New cards

Debugging – Stabilization/Reproduction

Phase where a minimal test case that reliably triggers the defect is produced.

70
New cards

Debugging – Localization

Process of finding the exact code section responsible for a defect.

71
New cards

Debugging – Correction

Modifying code to eliminate the located defect.

72
New cards

Debugging – Verification

Confirming the fix and ensuring no regressions, often using tools like source comparators or interactive debuggers.

73
New cards

Source Code Comparator

Tool that highlights differences between code versions to aid verification (e.g., Code Compare).

74
New cards

Interactive Debugger

Tool that allows step-through execution, variable inspection, and breakpoint control during debugging.

75
New cards

Assertion

Executable statement that checks a condition assumed true; used for defensive programming.

76
New cards

Defensive Programming

Technique of writing code that anticipates and guards against possible errors or misuse.

77
New cards

Profiler

Performance tool that measures resource usage to guide optimization.

78
New cards

Refactoring

Improving code structure and readability without altering external behavior.

79
New cards

Code Smell

Surface indication that usually corresponds to a deeper problem (e.g., duplicated code, long methods).

80
New cards

Long Method (Smell)

Excessively lengthy routine; often refactored by extracting smaller functions.

81
New cards

Feature Envy (Smell)

Method that excessively uses data or methods of another class, suggesting a relocation of logic.

82
New cards

Three Golden Rules of UI Design

1) Place user in control, 2) Reduce user memory load, 3) Ensure consistency.

83
New cards

Place User in Control

UI principle where operations are reversible and users initiate actions rather than react to system behavior.

84
New cards

Reduce User’s Memory Load

Design guidance to minimize the amount of information users must remember by keeping cues visible.

85
New cards

Consistent User Interface

Maintaining uniform visual and interaction patterns across an application to enhance learnability.