CS 2340 Midterm

Objects and Design Midterm 1

Waterfall Methodology

Very drawn out, lots of documentation that isn’t coded until it is complete.

Waterfall Pro and Con

Pro: Finds errors early

Con: Not flexible and doesn’t have a high project completion rate

Agile Methodology

>Individuals and interactions over processes and tools

>Working software over comprehensive documentation

>Customer collaboration over contract negotiation

>Responding to change over following a plan

Agile Pros

Favors code over having massive amounts of documentation so more projects are completed and are satisfactory to the customers

Differences of Waterfall and Agile

Agile is adaptive and is always doing incremental designs and is being reproved by the customers.

Waterfall takes time to get all of the customers desired functionality and features and puts them into code and gives a product

Principles of Agile Development

Just read the picture or don’t idc

EXtreme Programming

A lightweight agile methodology that focuses on having very short iteration cycles so that things are quickly and iteratively getting better

Characteristics of XP

Lightweight, Humanistic, Disciplined, and Software Development

XP Practices: Thinking

> Pair Programming

> Energized work

> Informative Workspace

> Root-cause analysis

> Restrospectives

XP Practices:

Collaborating

> Trust

> Sit together

> Real Customer Involvement

> Ubiquitous Language

> Stand-Up Methods

> Coding Standards

> Iteration Demo

> Reporting

XP Practices:

Releasing

> “Done Done”

> No Bugs

> Version Control

> Ten Minute Build

> Continuous Integration

> Collective Code Ownership

> Documentation

XP Practices:

Planning

> Vision

> Release Planning

> The Planning Game

> Risk Management

> Iteration Planning

> Slack

> Stories

> Estimating

XP Practices:

Developing

> Incremental Requirements

> Customer Tests

> TDD

> Refactoring

> Simple Design

> Incremental Design and Architecture

> Spike Solutions

> Performance Optimizations

> Exploratory Testing

Pair Programming

the “Driver” codes and the “navigator” thinks and they swap

Pros: Code that’s already reviewed and more fun

Cons: Possibly the work is half as efficient

Root Cause Analysis

Ask why 5 times

Ubiquitous Language

Simple talking so everyone is on the same page

Done Done

> Tested \n > Coded

> Refactored

> Integrated

> Builds \n > Installs

> Migrates

> Reviewed

> Fixed \n > Accepted

Stories

One- or two-line descriptions of work the team should produce

Customer Test

Check for very specific functionality and desired features

Scrum Actors

> Product Owner is the customer

> Developer Team

> Scrum Master leads dev team in features from product backlog and such

Scrum Process

Check Diagram or don’t choose your own adventure

Sprint Planning

Choose items from backlog to put into sprint backlog

Takes roughly 4 hours for a 2 week sprint

Daily Scrum

Everyone is asked these questions:

> What was done yesterday?

> What needs to be done today?

> What obstacles have been met?

Takes roughly 15 minutes

Sprint Review

Team demos product and product backlog is revisited as needed and product is released

Takes roughly 2 hours

Sprint Retrospective

Team reflects on the process and what went well and what needs to be improved for next sprint

Takes roughly an hour and a half

Scrum Ceremonies

Sprint Planning,Daily Scrum, Sprint Review, Sprint Retrospective

Artifact

any work product that is produced and used during a project

Domain

the targeted subject area of a computer program

Functional Requirements

Features and capabilities,

Non-Functional Requirements

>Usability

> Security

> Reliability

> Performance

Use Case Model

A set of typical scenarios of using a system

User Stories

As I want to so that

Where do requirements come from?

>Stakeholders

> Application Domain

> Documentation

Steps to Analyze Requirements

> Verification

> Validation

> Risk Analysis

Requirements Verification

Make sure the right product is being built

Requirements Verification

Product is being built right

Why do we prioritize requirements?

> Limited Resources

> Inability to satisfy all the requirements

Domain Model

a visual representation of conceptual classes or real-situation objects in a domain

> Remember that this deals with Conceptual Classes

> Remember that it does NOT show Software classes

Methods to find Conceptual Classes

> Reuse or modify existing models

> Use a category list

> Identify noun phrases

Association

A relationship\[ between classes that indicates some meaningful and interesting connection

Roles

Each end of an association is a role and roles can have:

> multiplicity expression

> name

> navigability

Multiplicity

The number of inputs or outputs between conceptual classes

Ex.

\* zero or many

1\..\* one or many

etc.

Attributes

logical data value of an object

Derived Attributes

If an attribute’s value can be derived by the values of other attributes than its a derived attribute

Use Cases

> Have a long history

> Describe how the system will act based off of interactions with its end user

> Primarily used to document functional requirements

> More Detailed

> Focuses on the functionality of a feature or process

User Stories

> More recent approach

> Simple informal way to describe user needs

> provided in small increments

> can be viewed as a subset of a use case

> Less Detailed

> Who, what, and Why of a project

Use Case Structure

> Actor/User

> SuD

> Goal

> Preconditions

> Main Success Scenario

> Alternate Scenarios

> Postconditions

Primary Actor

Has a gaol fulfilled through using services of the SuD

Supporting Actor

Provides a service to the SuD

Offstage Actor

Has an interest in the behavior of the use case, but it not a primary or supporting

Use Case: Fully Dressed Style

Has additional scenarios, special requirements, and technology and data variation lists

Use Case Validity Tests

Elementary Business Process Test: adds measurable business value

Boss Test: Would this be acceptable to tell a boss the amount of work or type of work you’ve been doing

Size Test: many steps and not a single step within a series of steps

Essential Use Cases

Focus is on intent, stray away from UI decisions

Concrete Use Cases

UI Decisions are embedded in the use case text

Use Case Diagram Structure

actors as stick figures, use cases as elapses, and line associations

Use Case Includes

* when a case is used by another case
* several use cases
* has a uses relationship
* depicted with an arrow with a dotted line pointing to the child case

Use Case Extends

* Exceptions to the typical path of a use case
* depicted with a dotted arrow that points to the base use case

Use Case Model

A set of all use cases in text

Use Case

One or more scenarios of use written in text form

Use Case Diagram

Graphical Depiction of the use case model

git clone (repo name)

Clone the given repo onto your machine

git add (file(s))

Stages all files to be committed to a branch

git commit -m “descriptive message“

Commit a staged snapshot of your code and add a message

git push

Push branch and all commits and objects into remote directory

git pull

Gets a specified copy of the current remote branch that is connected to the branch your working in and merge it into the local copy

git fetch

Fetches a specific branch, from repo

git status

List which files are staged, not staged, and untracked

git branch

States the current branches you have checked out and highlights the current branch that is being worked in

git checkout

Opens up a new branch from remote and allows a user to edit and work in that checked out branch

git merge “branch name“

Merges your current branch into the given branch name and overwrites it

Local vs Remote

Local is on your physical machine

Remote is on the cloud in a cloud server that can be asked on your computer

3-Stage process for making a commit and pushing to a Remote repository

git add .

git commit -m “Descriptive Message“

git push

Create a new branch

git checkout “branch name of your choosing“

Merge into main branch

make sure your in your desired branch

git merge main

Pull Requests

Helps to alleviate merge conflicts and helps to explain the rest of them. It compares your code to the merging into branch for clarity and to show changes over a file

Commit Message Content

A Present Tense descriptive message about the changes

System Sequence Diagram (SSD)

A picture that shows, for a particular scenario in a use case, the events that external actors generate, their order, and possible intersystem events

> Systems are treated as a Black Box

> Focuses on events that cross the system boundary from actors to systems

> Dynamic Diagram

Arrows in an SSD

> Vertical Line is a Lifeline

> Arrows to system are functions

> Arrows to actor are outputs

SSD: Loop Fragment

Just a for/while loop

SSD: Alternatives (Alt)

If/else statements

SSD: Option (Opt)

Literally just an If statement

SSD: Reference (Ref)

A reference that both the system and actor use

Sequence Diagram

Models the interactions between objects in a system and the order in which they are processed

> Part of the object oriented design stage

> Dynamic Diagram

> Shows all of the system instead of hiding it in a box

> Same fragments as SSD

> ;Actor

> :System

Activation Bar

A line on the SD to show when something is instantiated for the first time

Four Pilars of OOP

> Inheritance

> Encapsulation

> Polymorphism

> Abstraction

Visibility Between Objects

> Attribute

> Parameter

> Local

> Global

Software Development and Design Acronyms

> DRY: Don’t repeat yourself

>SoC: Separation of Concerns

> KISS: Keep it simple stupid

> YAGNI: You aren’t going to need it

> LGTM: Looks good to me

Attribute Visibility

> Visible when B is an Attribute of A

> Relatively permanent visibility

Parameter Visibility

> Visible when B is passed into A

> Relatively temporary visibility

Local Visibility

> B is a local object in method A

> Relatively temporary visibility

Implement Classes in DCD

Do so starting with the class that has the least number of other classes in relation to it so that its easier to build up the code files

Aggregation Relationship

When one object needs another to fully define itself as an object

Design Class Diagram (DCD)

Shows a system with software classes and attributes

> Different than Domain Model because it shows actual classes and attributes that can be converted to code

> Static Diagram

DCD Class Structure

> Class name at the top of the box and enclosed by a line

> attributes of the class in the second box if there are any and they are set up as “(Visibility Symbol) Name: data type“

> Operations/Methods that doesn’t need to include getters/setters and all other methods should be there except for inherited methods

DCD Class Visibilities

\+ Public

\# Protected

\- Private

/ Derived

DCD Relationships: Generalization

> X is a Y

> Inheritance relationship\[ between classes or implementation

> Solid arrow with an empty tip

DCD Relationships: Realization

> X is a Y

> Interface implementation

> Dotted line with an empty tip

DCD Relationships: Dependencies

> X uses a Y

> method of a class that uses another class’s object as a parameter

> Dotted line with an filled arrow head

DCD Relationships: Aggregations

> X has a Y

> Relationship between the whole and the part but the whole and part can be separated

> Solid line with an empty diamond

DCD Relationships: Composition

> X has a Y

> Relationship between the part and the whole but the part and whole can’t be separated

> Solid line and filled diamond