Glossary

Estimated time to read: 5 minutes

abstract - in object-oriented design, a class that cannot be instantiated directly, but must be subclassed
abstract data types - data types that are defined by the their behaviour as opposed to their structure. Defined by the developer rather than the programming language
access modifiers - keywords that control which other classes can access a variable or method in a class. In Java these include public, protected, private, and no keyword, sometimes called default.
abstraction - the act of simplifying a concept in context. In object-oriented design, it is the simplification of the real world entity into its most important attributes and behaviours for the purpose of the software.
attribute - a property that object of a class must have, even though their values may be different. For example, two student objects each have a grade attribute, even though one has an 'A' and the other has a 'B.'
behaviours - the actions that an object can take
boundary object - an object whose role is to interface with an external component, such as a user or an adjacent system
class diagram - a UML diagram for showing the behaviours, attributes, inheritance, and connections of classes
code review - systematic reviews of written code done by the development team. Not only to find mistakes, but to get developers using the same conventions, constructs, design principles, etc.
cohesion - describing the complexity within a module, e.g. a class or a method. high cohesion describes a module that has a clear purpose and is no more complex than it needs to be. low cohesion describes a module which has an unclear purpose or which is overly complex.
component - a discrete part that has a particular role or function, called a responsibility. From a design perspective, a component will eventually be turned into an object, function, or group of subcomponents
conceptual integrity - the consistency of software. Software with conceptual integrity will seem like it is programmed by one developer, even if it was programmed by a team
concern - a general term, referring to some action or role that is part of the solution to the problem.
control object - an object whose role is to manage other objects or control their interactions
counterexamples - during model checking, counterexamples are instances wherein the system did not behave as expected
coupling - describing of the complexity of connections between modules. tightly coupled modules are highly dependent on each other and difficult to reuse in other contexts. loosely coupled modules are less dependent and easier to reuse.
CRC - stands for class responsibility collaborator: a technique for summarizing and mapping objects in an object-oriented design.
deadlock - a situation in which the system can never continue because subprocesses need other subprocesses to act before they can continue
decomposition - breaking an entity into parts that can be implemented separately
degree - when talking about coupling, degree is the number of connections between the two modules of interest. This is one dimension of how coupled these modules are.
design - the process of planning a software solution, taking the requirements and constraints into account. Divided into higher-level conceptual design and more specific technical design.
design patterns - established solutions to common coding problems. Characterized by their general form and function rather than by specific code
ease - when talking about coupling, ease is how obvious connections are between modules. This is one dimension of how coupled these modules are.
encapsulation - bundling attributes and behaviours into an object, exposing features of that object to other objects as necessary, and restricting the remaining features
entity - the role or behaviour that is being represented by a software object or process
flexibility - when talking about coupling, flexibility is how easily a module can be swapped for a different module. This is one dimension of coupling.
getter - a method for getting the value of a class variable which is not directly accessible
generalization - factoring out common features of classes or functions that can be reused in other places. Allows for more code reuse
global variable - a variable that is accessible by any subroutine or subcomponent
flexibility - the ability of a design to adapt to changes or be adapted to different purposes
implementation - the process of creating a working program from the design
information hiding - designing classes so that the information that other classes do not need is hidden away from them.
inheritance - attributes or behaviours that subclasses inherit from a superclass or implement through an interface
instantiate - to create an object of a class
interface inheritance - a method of inheritance wherein if a class implements an interface, it must define all the methods specified in the interface
Liskov substitution principle - a principle stating that a superclass should be able to be replaced by its subclass without changing behaviour significantly
local variable - a variable accessible only to one class or subroutine
maintenance - modifying software after delivery to fix, improve, or change features
maintainable - the ability of code to be changed
model - an abstract representation of the key concepts and relationships that make up a software solution
model checking - a systematic check of all of the system's states. Consists of several steps: modeling phase, running phase, and analysis phase
module - general term to refer to a programming unit, like a class or a method.
namespace - an abstract container for a group of related modules, given a unique identifier.
object-oriented modelling - modelling a software solution using concepts from object-oriented languages such as Java. Characterized by representing key concepts with software objects.
override - a subclass may have a method that is already in the superclass, in which case the subclass' method will be used instead.
package - a means of organizing related classes into the same namespace.
polymorphism - the ability to interact with objects of different types in the same way. Usually achieved through inheritance or through interfaces in Java
programming paradigm - the style or way in which programming achieves its objectives, which can vary by language and toolset
quality attributes - properties of a software system that indicate its quality
requirements - the requirements that the software will be designed to fulfill. These could be functional requirements such as providing some result, or business requirements such as being user-friendly, or meeting budgetary restrictions
responsibility - the purpose or function of a component of the software
reusable - the ability of code to be reused in different contexts
rule of least astonishment - a design principle dictating that a component should behave as one would expect it to behave
separation of concerns - a principle dictating that different concerns should be in different modules
service-oriented architecture - a type of architecture characterized by providing services to external clients. The clients do not know how these services are provided.
sequence diagram - a UML diagram that shows the sequence of actions that form one process
setter - a method for setting the value of a class variable which is not directly accessible. Allows for gatekeeping e.g. restricting the values to which the variable can be set
software architecture - the higher-level structure of a software system; how various components are arranged into a coherent and functional whole
state diagram - a UML diagram that shows the different states of a system
tradeoff - a decision between alternatives that each provide benefits and downsides
Unified Modelling Language - a visual design language encompassing many different diagrams that depict software in different ways
verification - confirming that the software solution meets the requirements