CS 2340 Notes

Waterfall method

A project progression method that follows a sequential and linear approach, where each phase must be completed before the next one can begin.

Agile methodology

A highly iterative and incremental development process that is flexible compared to the Waterfall method.

Extreme Programming (XP)

A software development methodology that emphasizes practices such as incremental planning, small releases, test-first development, and pair programming.

Pair programming

A practice in Extreme Programming where two programmers work together on the same machine, aiming to improve code quality and accelerate knowledge transfer.

Customer tests

Tests that help identify and fix bugs early in the development process, leading to improved software quality and increased customer satisfaction.

Scrum

A framework for managing and organizing Agile development, involving roles like Product Owner, Team, and Scrum Master.

Scrum ceremonies

Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective, each serving different purposes in the Scrum process.

Refactoring

The process of improving the structure and design of existing code without changing its external behavior, important for the long-term sustainment of software systems.

Software architecture

The design and structure of a software system, including different types such as client-server architecture.

Design stamina hypothesis

Considering the impact of design changes on business and making data-driven decisions to avoid wasting time and resources.

Client-server architecture

A system where clients call on services offered by a server, often organized in a two-tier architectural style with physical and logical separation.

Scalability

The ability of a system to handle increasing amounts of work or data.

Organization

The arrangement and management of resources in a systematic way.

Efficiency

The ability to accomplish a task with minimum wasted effort or resources.

N-Tier architecture

A system architecture where different layers of the system are separated processes that may execute on different processors.

Denial-of-service attacks

Attacks that aim to make a service or network unavailable to its intended users.

Server failures

Instances where a server stops functioning properly.

Peer-to-Peer

Decentralized systems in which computations can be carried out by any node on the network.

Computationally intensive

Systems that require a significant amount of computational power.

Redundant

Having multiple instances or backups to ensure fault-tolerance.

Blackboard/Shared Memory

A system where a blackboard is iteratively updated by a diverse group of specialist knowledge sources.

Pipe and Filter

A data-centric style structure where data flows through the application and transformations are performed on it.

Workflow

The sequence of tasks or activities that need to be completed to achieve a specific goal.

Layered system

Organizing a system into layers with related functionality/logic associated with each layer.

Model-View-Controller (MVC)

A layered approach where the user interacts with the controller, which manipulates the model and updates the view.

Model-View-ViewModel (MVVM)

Derived from MVC, where the business logic is separate from the view.

Event Driven Architecture

A system architecture where event producers generate events and event consumers listen for those events.

Microservices

Small, independent, self-contained services that perform specific functions in an application.

Functional requirements

Specific tasks or functionalities that a system should perform.

Non-functional requirements

Criteria used to judge the operation of a system, such as security, accuracy, performance, cost, usability, adaptability, and reusability.

Requirements Engineering

The process of establishing the needs of stakeholders that software needs to solve.

Stakeholders

Individuals or groups affected by the system or its functionality.

Application domain

The specific area or industry for which the software is being developed.

Verification

The process of ensuring that requirements accurately reflect customer needs. Focuses on the quality of the software, including completeness, pertinence, testing, inspection, and design analysis.

Validation

The process of ensuring that the system reflects stakeholders' requests.

Requirement Engineering: Risk Analysis

The evaluation of potential risks and their impact on the system.

Domain Model

A visual representation of conceptual classes or real situation objects in a domain and their relationships based on system requirements.

Conceptual classes

Real-world classes represented in a domain model, not software classes.

Use Cases

Descriptions of how the system will act based on interactions with its end users (actors), primarily used to document functional requirements.

User Stories

Provided in small increments, can be viewed as a subset of use cases.

Acceptance criteria

Given, And, When, Then statements that define the expected outcomes of a user story.

Use Case Structure

Actor/user, SuD, Goal, Preconditions, Main success scenario, Alternate scenario, Postcondition.

Brief Use Case

One paragraph summary of functionality.

Casual Use Case

Multiple paragraphs that cover multiple scenarios.

Fully-dressed Use Case

Structured, detailed description of scenarios.

Essential Use Case Style

Focuses on the core functionality and main success scenario.

Concrete Use Case Style

Includes more detailed steps and alternate scenarios.

Use Case Model

A collection of use cases that describe the behavior of a system.

Use Case Diagram

A diagram that shows the relationships between actors, use cases, and their associations.

Primary Actor

Has user goals fulfilled through using services of the SuD (e.g., library member, librarian).

Supporting Actor

Provides service (e.g., authorization service, payment service).

Offstage Actor

Has an interest in the behavior of the use case but is not primary or supporting (e.g., district regulating agency).

Version Control

A system that tracks changes to files over time, allowing for reverting to previous versions and collaboration.

git clone

Creates a local copy of a remote repository.

git add

Adds a file or set of files to the staging area.

git commit

Commits the changes in the staging area to the local repository.

git push

Pushes the local commits to the remote repository.

git pull

Pulls the latest changes from the remote repository to the local repository.

git status

Shows the status of the working directory, including modified and staged files.

git branch

Creates a new branch.

git checkout

Switches to a different branch.

git switch

Switches to a different branch (similar to git checkout).

Local repository

A repository stored on the user's local machine.

Remote repository

A repository stored on a remote server, typically used for collaboration.

Remote repository

A copy of a repository stored on a server.

3-stage process for making a commit and pushing to the remote repository:

• Make Changes to file and stage changes using git add

• Commit changes using git commit

• Push changes to the remote repository using git push

Create a new branch

git branch

Switch branches

git switch/checkout

Merge a feature branch into the main branch

git merge

Pull request

A way to request that your changes be merged into another branch. Used for collaboration.

Good commit messages

Concise, clear messages that give a general summary of the changes done.

Bad commit messages

Vague messages that don’t relay any information.

Creational design pattern

A type of design pattern that focuses on object creation mechanisms.

Structural design pattern

A type of design pattern that focuses on the composition of classes and objects.

Behavioral design pattern

A type of design pattern that focuses on the interaction between objects.

Singleton design pattern

A creational pattern that restricts the instantiation of a class to one object.

Real-world examples of Singleton design pattern

Logging systems, database connections, configuration managers.

System Sequence Diagram (SSD)

A dynamic diagram that shows the sequence of events between actors and the system. Also shows the sequence of events that occur over time.

Actor

An entity that interacts with the system from the outside.

System events

Events that occur within the system triggered by an actor or another system event.

alt (Alternatives) fragment

Used when a choice needs to be made between two or more message sequences.

loop (Loop) fragment

Represents a repetitive sequence until a condition is met.

opt (Option) fragment

Semantically equivalent to a simplified alternative fragment to model "if then" sequence.

What determines the direction and order of messages in an SSD?

determined by the sequence of events that occur when an actor interacts with the system. Messages are typically sent from the actor to the system, and then from the system back to the actor.

Solid line communications

Represent synchronous communications where the sender waits for a response.

Dotted line communications

Represent asynchronous communications where the sender does not wait for a response.

Sequence Diagram (SD)

Illustrates the interactions between objects in a system over time.

SD's relation to use cases

Based on use cases, which describe specific interactions between actors and the system.

SD's place in the project design process

Lies in the overall project design process to visualize object interactions.

SDD

_______ is a dynamic diagram. This means that it shows the sequence of events that occur over time.

Difference between SD and SSD

SD shows interactions between objects, while SSD focuses on interactions between actors and the system.

Syntax of representing objects in SD

Objects are represented by rectangles with the object name inside. Activation bar represents the time an object is active.

Lifeline of objects in SD

Represented by a vertical line extending from the object's rectangle.

Design Class Diagram (DCD)

Illustrates the specifications for software classes and interfaces in an application.

DCD's relation to Domain Model

Differs by showing software entities rather than real-world concepts.

OOA diagram

Object-Oriented Analysis diagram, a visual representation of the analysis phase of software development, depicting the objects, their attributes, and their relationships.

Is a DCD a static or dynamic diagram?

dynamic