CSC207 Software Design: Exceptions, Testing, GUIs, Ethics, SOLID, and Clean Architecture

Comprehensive vocabulary flashcards covering Java exceptions, GUI design with Swing, unit testing with JUnit 5, user stories, ethics of accessibility, SOLID design principles, and Clean Architecture engine components.

Checked Exceptions

Exceptions in Java (subclasses of Exception, excluding RuntimeException and its subclasses) that the compiler requires the caller to either catch in a try-catch block or declare using the throws keyword.

Unchecked Exceptions

Exceptions belonging to Error and RuntimeException (and their subclasses) that Java does not require to be caught or declared at compile time, typically indicating programming errors or unrecoverable conditions.

Throwable Hierarchy

The root hierarchy in Java for all errors and exceptions, splitting into Error (serious, unrecoverable system conditions) and Exception (conditions that a program can reasonably handle or recover from).

Javadoc

A formal documentation block format placed above classes, member variables, and methods using the /** … */ syntax to generate standardized HTML API documentation.

CheckStyle

A static analysis tool that performs automated checks to enforce style conventions and best-practice coding standards on Java source code.

UML Class Diagram Notation

A visual modeling legend where + denotes public, - denotes private, # denotes protected, ~ denotes package-private, italics/«abstract» denote abstract elements, underlines denote static elements, dashed arrows with closed triangles denote implements, and solid arrows with closed triangles denote extends.

Java Swing

A graphical user interface (GUI) toolkit in Java for building event-driven desktop user interfaces, consisting of component classes that mostly start with 'J' (such as JButton, JLabel, and JPanel).

Layout Manager

A Swing object (such as FlowLayout or BoxLayout) associated with a container like JPanel that automatically determines the positioning, alignment, and sizing of nested components.

ActionListener

A Java Swing interface containing the actionPerformed(ActionEvent e) method, implemented to respond to user GUI events such as button clicks.

JUnit 5 Lifecycle Annotations

Annotations controlling test execution order: @BeforeAll (initial setup once), @BeforeEach (setup before each test), @Test (actual test case), @AfterEach (teardown after each test), and @AfterAll (final teardown once).

Test-Driven Development (TDD)

A software engineering methodology where unit tests based on requirements are written before writing the implementation code itself.

User Story

A lightweight description of a feature focused on end-user value, structured as: 'As a [kind of user], I want to [accomplish a goal] so that [I receive some benefit]'.

Medical Model of Disability

A framework where disabilities are viewed as personal or social limitations caused directly by a physical or mental impairment, treating the human environment as a background condition.

Social Model of Disability

A framework where disabilities are viewed as limitations caused by the human world (through societal stigma or environmental design), treating the physical or mental impairment as a background condition.

Material Harms

Tangible negative consequences suffered when excluded from using software, including losses to health, happiness, wealth, freedom, or social opportunities.

Relational Harms

Harms that occur when words, actions, or software design decisions convey that certain individuals or groups are less than equal, demoting their social standing and dignity.

Use Case

A detailed specification describing step-by-step interactions between an actor and a system to achieve a goal, specifying the primary actor, preconditions, trigger, main success scenario, extensions, and success outcome.

Sequence Diagram

A UML behavioral diagram illustrating how objects interact over time by showing lifelines and the sequence of method calls and return messages for a specific scenario.

High Cohesion

A design quality where the attributes, methods, and responsibilities of a single class all strongly relate to one another and belong together.

Loose Coupling

A design quality where direct dependencies between classes are minimized and bidirectional dependencies are eliminated.

The SOLID Principles

A set of five object-oriented design principles: Single Responsibility Principle (SRP), Open Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP).

Single Responsibility Principle (SRP)

The SOLID principle dictating that a class or module should have one clear responsibility and only one reason to change.

Open Closed Principle (OCP)

The SOLID principle specifying that software components should be open for extension (adding new functionality) but closed for modification (leaving existing code unchanged).

Liskov Substitution Principle (LSP)

The SOLID principle requiring that subtypes must be substitutable for their supertypes without altering the correctness or behavior of the program ('Subtypes should behave like their parent type').

Interface Segregation Principle (ISP)

The SOLID principle asserting that clients should not be forced to depend on methods they do not use ('Don\'t force unnecessary methods on a class').

Dependency Inversion Principle (DIP)

The SOLID principle establishing that high-level modules should not depend on low-level modules, but both should depend on abstractions/interfaces ('Depend on interfaces, not implementations').

Clean Architecture Layers

An architectural model organized into four concentric circles: Enterprise Business Rules (Entities), Application Business Rules (Use Cases), Interface Adapters (Controllers, Gateways, Presenters), and Frameworks & Drivers (UI, Database, Web, Devices).

The Dependency Rule

The core rule of Clean Architecture stating that source code dependencies must only point inward; code in an inner layer must never name or depend on elements from an outer layer.

Entities (Clean Architecture)

Domain objects embodying Enterprise Business Rules and critical business data at the innermost core of the architecture, remaining completely independent of use cases and external systems.

Use Case Interactor

A class within the Application Business Rules layer that implements an Input Boundary to execute business logic, manipulate Entities, access data via Data Access Interfaces, and pass Output Data to the Output Boundary.

Controller (Clean Architecture)

An Interface Adapter component that receives raw user input from the View, packages it into an Input Data data structure, and calls the Use Case Input Boundary.

Presenter (Clean Architecture)

An Interface Adapter component that implements the Output Boundary, formats Output Data from the Interactor into displayable strings/numbers, and updates the View Model.

View Model (Clean Architecture)

An observable state container in the Interface Adapters layer holding the presentation data required by the View to render information.

Input Boundary

A Java interface in the Application Business Rules layer defining the method contract (e.g., execute(InputData)) used by the Controller to trigger a use case.

Output Boundary

A Java interface in the Application Business Rules layer defining the methods (e.g., prepareSuccessView, prepareFailView) through which the Interactor transmits results to the Presenter without depending on it directly.

Data Access Interface (DAO Interface)

An interface located in the Application Business Rules layer specifying persistence operations (such as existsByName and save) required by the Interactor, implemented by concrete storage mechanisms in outer layers.

The CA Engine

The flow-of-control pipeline connecting View -> Controller -> Input Boundary / Interactor -> Entities / Data Access -> Output Boundary / Presenter -> View Model -> View.

AppBuilder

A class belonging to the Main component that instantiates concrete Views, View Models, Presenters, Interactors, and Data Access Objects, wiring dependencies together to construct the application window.

Integration Test (Clean Architecture)

A test that verifies the interaction between two or more architectural components across boundaries, specifically how a Use Case Interactor works with a real database or Data Access Object.

End-to-End Test (Clean Architecture)

A comprehensive test that exercises an entire use case path starting at the user interface (View) and continuing through all layers to data persistence and back.