CS 2340 Exam 2

Single Responsibility Principle (SRP)

A class should have a single overriding responsibility; it should have only one reason to change[cite: 1, 3].

Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification; extend behavior by adding new code, not changing old code[cite: 1, 3].

Liskov Substitution Principle (LSP)

Subclasses should be substitutable for their base classes without altering the correctness of the program[cite: 1, 3].

Interface Segregation Principle (ISP)

Don't make large multipurpose interfaces; clients should not be forced to depend on interfaces they don't use[cite: 1, 3].

Dependency Inversion Principle (DIP)

Depend on abstractions, not concretions; high

Preconditions (LSP)

According to Design by Contract, these cannot be strengthened in the subclass[cite: 1, 3].

Postconditions (LSP)

According to Design by Contract, these cannot be weakened in the subclass[cite: 1, 3].

Creator (GRASP)

Assign class B the responsibility to create class A if B contains, aggregates, records, or closely uses A[cite: 2].

Information Expert (GRASP)

Assign a responsibility to the class that has the information necessary to fulfill it[cite: 2].

Controller (GRASP)

The first object past the UI that receives and coordinates a system operation; delegates work but doesn't do it itself[cite: 2].

Low Coupling (GRASP)

Assign responsibilities so that dependencies between classes remain as low as possible to reduce the impact of change[cite: 2].

High Cohesion (GRASP)

Assign responsibilities so that objects remain manageable, focused, understandable, and do not do many unrelated things[cite: 2].

Content Coupling

The worst type of coupling; occurs when one class modifies another's internal data or branches into the middle of a routine[cite: 2].

Common Coupling

A bad form of coupling where classes share common (global) data[cite: 2].

Control Coupling

A bad form of coupling that uses a return code to control a different method's execution flow[cite: 2].

Stamp/Data Coupling

An acceptable form of coupling that involves passing complex data or structures between modules[cite: 2].

Coincidental Cohesion

The worst type of cohesion; completely unrelated functions are grouped in a single module[cite: 2].

Logical Cohesion

A bad form of cohesion where multiple logic sections are grouped together, usually executed based on a flag[cite: 2].

Functional Cohesion

The best type of cohesion; all essential elements for a single function are in the same module[cite: 2].

Novice Developer

Creates brittle designs that are easy to code but hard to maintain[cite: 2].

Intermediate Developer

Creates overly fancy, flexible, generalized designs that are easy to maintain but hard to code[cite: 2].

Expert Developer

Creates designs chosen with insight, balancing brittle with generalized implementations[cite: 2].

Software Architecture

The structure(s) of a system, comprising elements, externally visible properties, and the relationships among them[cite: 5].

Architectural Style

Determines the vocabulary of components, connectors, and constraints on how they can be combined[cite: 4, 5].

Logical View (4+1 Model)

Focuses on the object model of the design to address end

Process View (4+1 Model)

Captures concurrency, synchronization, and distribution aspects, addressing performance and scalability[cite: 6].

Development View (4+1 Model)

Describes the static organization of software modules in the development environment[cite: 6].

Physical View (4+1 Model)

Describes the mapping of the software onto the hardware network, addressing system topology and communications[cite: 6].

Scenarios (4+1 Model)

Uses instances of use cases to illustrate and validate the architectural views working seamlessly together[cite: 6].

Pipes and Filters Style

Components (filters) apply local transformations to input streams and produce output streams via connectors (pipes)[cite: 4].

Batch Sequential System

A degenerate case of a pipeline architecture where each filter completely processes all its input data before passing it on[cite: 4].

Data Abstraction / Object

Oriented Style

Event

based / Implicit Invocation Style

Layered System Style

Organized hierarchically, where each level provides service to the one above and serves as a client to the one below[cite: 4].

Repository Style

A central data structure represents the current state, and independent components operate on it (e.g., Databases, Blackboards)[cite: 4].

Table Driven Interpreter Style

A virtual machine produced in software containing an interpretation engine, memory, control state, and current program state[cite: 4].

KWIC (Key Word in Context)

A classic problem used to contrast the adaptability of different architectural styles like Shared Data, ADT, Implicit Invocation, and Pipes & Filters[cite: 4].

Design Pattern

A reusable micro

Class Jurisdiction

Patterns dealing with static semantic relationships between base classes and their subclasses using inheritance[cite: 8].

Object Jurisdiction

Patterns dealing with dynamic relationships between peer objects, relying heavily on object composition[cite: 8].

Compound Jurisdiction

Patterns that deal with behaviors and structures in recursive object structures[cite: 8].

Creational Patterns

Patterns that abstract how objects are instantiated, deferring the specifics of object creation[cite: 8].

Structural Patterns

Patterns that deal with the composition of classes or objects to form larger, more complex structures[cite: 8].

Behavioral Patterns

Patterns that characterize the ways in which classes or objects interact and distribute responsibility[cite: 8].

Abstract Factory Pattern

A creational object pattern providing an interface for creating families of generic product objects without specifying their concrete classes[cite: 8].

Strategy Pattern

A behavioral object pattern that objectifies an algorithm, allowing it to be selected and replaced at run

Wrapper / Decorator Pattern

A structural compound pattern that attaches additional services or properties to individual objects dynamically and transparently[cite: 8].

SimUDuck

A case study showing the Strategy pattern by extracting varying flying and quacking behaviors into interchangeable interfaces (FlyBehavior, QuackBehavior)[cite: 7].