81 key terms

Software design· foundations

Construction of abstractions of data & computation, organised into a working application; both a process and an outcome.

Quality attribute· foundations

A property design trades off, e.g. maintainability, reusability, security, performance, ease of implementation.

SDLC· processes

Software Development Life Cycle — a process for planning/managing development to meet requirements.

Waterfall· processes

Traditional engineering perspective; feasible for clear/static requirements; assumes frozen requirements; good for documentation.

V-Model· processes

Extension of the Waterfall; focus on testing and validation; widely used in safety-critical domains.

Spiral model· processes

Integrates previous models; one loop is a waterfall; each loop leads to a prototype; emphasises managing costs and risks.

Prototyping· processes

Develop a prototype for feedback; refine prototype iteratively; often integrated in other processes.

Agile· processes

A mindset (Agile Manifesto) prioritising individuals and interactions, working software, customer collaboration, and responding to change.

Scrum· processes

Agile framework of fixed-length Sprints (one month) producing increments, with roles (Product Owner, Scrum Master, Developers), events and artifacts.

Sprint· processes

Fixed period of time for working (one month); structures all other activities; after each Sprint an increment exists.

Increment· processes

Usable software produced after a Sprint that moves towards the Product Goal.

Definition of Ready· processes

Optional within Scrum; defines when an item in the Product Backlog is ready to be worked on.

Definition of Done· processes

Defines the criteria for an item to be considered complete.

Functional requirement· processes

Functionality/behavior that a system offers.

Quality requirement· processes

Qualities of the system (non-functional; measurable under stated conditions).

Constraint requirement· processes

Limits that cannot be changed (e.g. a mandated technology or standard).

SMART· processes

Specific (simple), Measurable, Achievable, Relevant (realistic), Traceable — criteria for good requirements.

MoSCoW· processes

Prioritisation: Must / Should / Could / Won't have.

Use case· uml

Description of how a system shall be used or should behave.

«include»· uml

Use-case relationship: shared behaviour fully included in another use case.

«extend»· uml

Use-case relationship: optional/conditional behaviour added at an extension point.

Generalisation· uml

Inheritance relationship ('Car is a Vehicle'), hollow triangle.

Aggregation· uml

Parts exist without the whole (hollow diamond; independent lifetime; parts can be shared).

Composition· uml

Part only exists in one whole at a time (filled diamond; part deleted with whole).

Multiplicity· uml

How many instances participate in an association (0..1, 1, n, 1..*, *).

Abstract class· uml

Abstracted behavior of a collection of classes; cannot be instantiated (italic/{abstract}); single inheritance.

Interface (Java)· uml

A collection of behavior offered by an object of that type; no constructor; classes can implement multiple interfaces.

Robustness· quality

Ability of a system to cope with errors and erroneous input.

Precondition (@pre)· quality

Must hold before execution; the client's obligation.

Postcondition (@post)· quality

Must hold after execution; the method's obligation.

Invariant· quality

Class conditions that must be true whenever the object is accessible.

Design by contract· quality

Specify behaviour via preconditions, postconditions and invariants.

White-box testing· quality

Tests internal logic (based on the code structure).

Black-box testing· quality

Tests intended functionality (based on the specification).

Equivalence class· quality

A set of inputs the method treats the same; test one representative each.

TDD· quality

Test-Driven Development: red (failing test) → green (pass) → refactor.

Version control system· version-control

Software that tracks the changes to a file; enables history, revert, merge, and collaboration.

Commit· version-control

A collection of changes submitted to the repository.

HEAD· version-control

The most recent commit to a repository (or a branch of it).

Branch· version-control

A duplicate of the files in a repository; developed independently; deleted with the repo.

Fork· version-control

Same as a branch, except it is independent of the repository (survives deletion; merged via pull request).

Merge conflict· version-control

The system cannot automatically merge files; requires manual resolution.

Separation of concerns· manageable

Divide a system into units with minimal overlap (divide & conquer).

Encapsulation· manageable

Place data + operations in a unit, exposing only a controlled interface.

Information hiding· manageable

Reveal as little information to the outside as needed.

Coupling· manageable

Degree of interaction between units (minimise).

Cohesion· manageable

Degree to which a unit serves a single purpose (maximise).

DRY· manageable

Don't Repeat Yourself — each problem solved in exactly one place.

SOLID· reusable

Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion.

Single responsibility· reusable

A class has only one reason to change.

Open/closed· reusable

Open for extension, closed for modification.

Liskov substitution· reusable

Subclass objects must work wherever a superclass reference is used.

Interface segregation· reusable

Clients shouldn't depend on methods they don't use; split large interfaces.

Dependency inversion· reusable

Depend on abstractions; client codes against an ADT, provider implements it.

Enum· reusable

Set of fixed values/constants (listed names); no constructor needed; no inheritance but can implement interfaces.

Record· reusable

Java 14+ data carrier: auto fields, getters, constructor, toString.

KISS· reusable

Keep It Simple, Silly! — simpler solutions are less error-prone.

Polymorphism· creational

A unit having different behavior depending on its specific context: ad-hoc (overloading), subtyping (overriding), parametric (generics).

Generics· creational

Parametric polymorphism; improve readability, reusability, and robustness; ensure type safety via compiler checks.

Design pattern· creational

Solution pattern to a common (recurring) problem; not always applicable — must be adapted to the specific problem.

Singleton· creational

Restrict the instantiation of a class to a single instance.

Factory· creational

Define interface to create object, but defer instantiation to subclasses; decouples creation from concrete classes.

Race condition· concurrency-gui

Multiple threads accessing shared memory lead to unexpected behavior depending on thread interleaving.

Event Dispatch Thread (EDT)· concurrency-gui

Swing thread that executes event-handling; non-thread-safe UI work must run here.

SwingWorker<T,V>· concurrency-gui

Runs long background tasks off the EDT; T = return type of doInBackground, V = type for intermediate results (process).

Command· concurrency-gui

Encapsulate a request with all information needed to execute later.

Decorator· structural

Attach additional functionalities to an object (and be able to remove it again); to an object at runtime, not a class.

Facade· structural

Provides a unified interface for a unit; hides the implementation of a larger unit behind one interface.

MVC· architecture

Pattern to separate concerns for GUI software: Model (data/logic), View (UI), Controller (links model and view).

Observer· architecture

Define a one-to-many dependency between objects; when the subject changes, all observers update automatically.

Strategy· behavioral

Encapsulate different algorithms and allow to exchange these at runtime (composition, not inheritance).

Iterator· behavioral

Define access to elements in an aggregate object without exposing the underlying design.

Template Method· behavioral

Implement an extensible skeleton of an algorithm; subclasses refine individual steps without impacting the general structure.

State· behavioral

Separate state-dependent behavior into own, referenced units; fixed number of states, only one active at a time.

Software smell· smells

Any property of code that can hint at deeper problems; a symptom, not a defect by itself.

Defect· smells

An actual misbehaviour of the software (differs from a smell: a smell is a symptom, a defect is a bug).

Blob / god class· smells

A large class that acts as controller of many data classes; defines all functionalities and decisions; violates SoC/SRP.

Refactoring· smells

Changes to a software's internal structure to make it easier to comprehend, maintain, and modify without changing its (observable) behavior.

Technical debt· smells

Metaphor for future rework needed due to poor software design/code; accumulates interest over time.

Feature envy· smells

Methods rely more on data/behavior of another object than their own.

Shotgun surgery· smells

Modifying any code requires changes to various classes; violates single-responsibility and cohesion/coupling.