Object-Oriented System Analysis and Design

Vocabulary practice flashcards covering systems analysis, the SDLC, the Unified Process, and the core building blocks and pillars of object-oriented systems.

System

A set of related components that work together to produce specific results.

Everyday System

A system that is useful to an organisation, but operations can temporarily cope if it stops running (for example, a room-booking application for meeting rooms).

Mission-Critical System

A system vital to daily operations where business operations halt completely if it stops (such as a bank's ATM network or a hospital's patient record system).

Data

Basic raw facts that serve as the input or raw material for a system, such as an employee ID, $40$ hours worked, and an hourly pay rate of $\text{RM}18.00$.

Information

Data that has been processed and transformed into meaningful, actionable output (for example, calculating weekly pay of $\text{RM}720.00$ ready for an employee payslip).

Hardware (Information Systems)

The physical layer of an information system, including servers, workstations, PCs, and telecommunication networks.

Software (Information Systems)

The programs, applications, and tools that process data within an information system, such as a payroll application.

Processes (Information Systems)

The tasks, operational workflows, and procedures performed by users and IT personnel to achieve specific business results (such as a monthly pay run and approval).

Systems Analysis

A formal, problem-solving inquiry that breaks an existing system into parts to understand it, defining what the system must do and producing a requirements document.

Systems Design

A planned, systematic approach that plans how the system will meet defined requirements, producing architectural models and technical design specifications.

Systems Development Life Cycle (SDLC)

A classic software engineering framework structured into $5$ phases: Planning, Analysis, Design, Implementation, and Support.

Waterfall Model

A classic SDLC approach where each phase finishes completely before the next starts; it is simple to manage but slow to react when user requirements change.

Unified Process (UP)

An iterative object-oriented systems development methodology that organizes iterations across four distinct phases: Inception, Elaboration, Construction, and Transition.

Inception Phase

The initial Unified Process phase addressing whether the system is worth building, focusing on problem definition, business case, project scope, and feasibility.

Lifecycle Objectives Milestone

The go/no-go milestone ending the Inception phase, where stakeholders agree on project scope, initial risk lists, and cost/time estimates.

Elaboration Phase

The second Unified Process phase answering 'Can we build it, and how?', which models requirements, mitigates top architectural risks, and specifies class and sequence diagrams.

Lifecycle Architecture Milestone

The milestone concluding the Elaboration phase that establishes an executable, tested architectural baseline and refined construction plan.

Construction Phase

The third Unified Process phase focusing on building, coding, testing, and integrating the remaining system features across successive iterations.

Initial Operational Capability Milestone

The milestone ending the Construction phase indicating that a fully functional system with user documentation is ready for beta testing.

Transition Phase

The final Unified Process phase dedicated to user acceptance, data migration, beta defect resolution, training, and deployment.

Product Release Milestone

The concluding milestone of the Transition phase where users accept the finalized system for operational production use.

Functional View (UML)

A system modeling view represented by Use Case diagrams that describes what external actors can accomplish using the system.

Structural View (UML)

A system modeling view represented by Class diagrams that depicts static entities within the system and their relationships.

Behavioural View (UML)

A dynamic system modeling view represented by Sequence and Activity diagrams that illustrates how objects interact and exchange messages over time.

Systems Analyst

A core project team role that bridges business stakeholders and software developers by eliciting needs, modeling processes, and defining technical requirements.

Procedural Programming

A development paradigm where programs are organized as sequential lists of functions acting on shared, separately stored data, where modifying data can break multiple functions.

Object-Oriented Programming (OOP)

A development paradigm where programs are designed as collections of self-contained objects bundling data with the specific behaviours that manipulate that data.

Object

A runtime entity in an object-oriented system possessing an internal state, defined behaviours, and a unique identity.

State (Object-Oriented)

The condition of an object at a given time, defined by the specific values held in its attributes (for example, $\text{batteryLevel} = 82$).

Behaviour (Object-Oriented)

The actions, services, or operations an object is capable of performing, defined by its methods (for example, $\text{countSteps()}$).

Identity (Object-Oriented)

The intrinsic characteristic ensuring each object is unique and distinguishable from all other objects, even when attribute values are identical ($\text{watchA} \neq \text{watchB}$).

Noun Analysis

A requirements analysis technique where nouns in a problem statement are identified and filtered to determine candidate system classes and objects.

Class

A blueprint, template, or mould (analogous to an acuan kuih) that defines the common attributes and methods shared by its instantiated objects.

Attribute

A variable or data item that stores an object's state, displayed in the middle compartment of a standard UML class box.

Method

A function or service that an object performs, displayed in the bottom compartment of a standard UML class box.

Constructor

A dedicated method executed when a new object is created to allocate memory and initialize its starting attribute values.

Accessor (Getter)

A method designed to retrieve and return an attribute's value without altering the internal state of the object (e.g., $\text{getTitle()}$).

Mutator (Setter)

A method designed to modify or update an attribute's value, typically enforcing validation logic (e.g., $\text{setTitle("Run")}$).

Query Method

A method that evaluates an internal condition of an object and returns a boolean value of true or false (e.g., $\text{isEmpty()}$ or $\text{isOnProbation()}$).

Public Visibility ($$+$)

A UML access modifier denoting that a class member (attribute or method) is accessible from any external class.

Private Visibility ($-$)

A UML access modifier denoting that a class member can only be accessed or modified within the declaring class itself.

Protected Visibility ($\#$)

A UML access modifier denoting that a class member is accessible exclusively within the declaring class and its derived subclasses.

Message Passing

The communication mechanism in OO systems where a sender object triggers an action by invoking a method on a receiver object with arguments, receiving an optional return value.

Encapsulation

The OO pillar combining data and related methods into a single class while restricting direct external access to state using private attributes and public interfaces.

Abstraction

The OO pillar of exposing only essential, high-level features while hiding complex internal mechanics, allowing users to know WHAT an object does rather than HOW.

Inheritance

The OO pillar where a child class (subclass) acquires attributes and methods from an existing parent class (superclass) while adding specialized capabilities.

Superclass

A generalized parent class in an inheritance hierarchy whose properties and operations are inherited by one or more subclasses.

Subclass

A specialized child class that inherits structural elements and behaviours from a superclass and can introduce additional features or override methods.

IS-A Test

A verification guideline stating inheritance is only valid when the relationship can be read logically as 'Subclass IS-A Superclass' (e.g., StudentTicket IS-A Ticket; not Ticket IS-A Seat).

Polymorphism

The OO pillar meaning 'many forms' where an identical method call triggers different runtime behaviours depending on the concrete class of the receiver object.

Method Overriding

The mechanism where a subclass provides its own specific implementation of a method that is already declared in its superclass.