software midterm 3

use case

written description of how a user will perform a task on your system

use case description

• title

• rationale/description/goal

• actor/user

• preconditions

  • things that must have already happened in the system

• standard path/main success scenario (happy story)

  • what will usually happen, described as a series of steps

• alternate paths/extensions

  • variations on the above/edge cases

• post conditions

  • what the system will have done by the end of the steps

CRC

• classes, responsibilities, collaborators

  • identify classes, clarify responsibilities, and collaborators

  • focus on the primary objective of the system

  • apply design heuristics and principles

  • omit inessential details

class diagram

• rectangle w/ class name

• optional components

  • attributes

  • methods

• include only key attributes and methods

dependency

• A uses B

• weak, temporary relationship. Class A uses Class B for a moment, but doesn’t own it

aggregation

• A has a B

• the part belongs to the whole, but can survive without it

inheritance

• A is a B

• parent child relationship

• Class A is a specific version of the generic Class B

composition

• A has a B

• the part belongs to the whole and can’t survive without it

• if the parent dies, the child dies

association

• a generic relationship

• the two classes interact or know each other, but don’t necessarily fit the other categories

directed association

• one way street

• Class A knows about Class B, but Class B doesn’t know Class A exists

interface type

• describes a set of methods

• no implementation, no state

• class implements interface if it implements its methods

UML sequence diagrams

• each diagram shows the dynamics of a scenario

• focus on interaction among objects

• reads from top to bottom, lifeline per project

• strength: sequences

• limitations: not great for describing loops, partial order

• object diagram: class name underlined

UML state diagram

• one variant of finite automata

• used for classes whose objects have interesting states

• reactive systems

  • voice mail system

  • GUI

  • communication protocols

iterator pattern

used to traverse a collection of items without needing to understand how those items are stored

model

• backend structure

• holds the raw data, doesn’t care about visual representation

view

• visual representation

• responsible for displaying the data to the user

controller

• this handles user interaction

• interprets what the user wants to do

observer pattern

a design pattern where a subject maintains a list of dependent observers and automatically notifies them whenever its state changes

decorator pattern

• design pattern that dynamically adds behavior to an object by wrapping it in a decorator class that shares the same interface, providing a flexible alternative to subclassing

• relies on the interface or superclass to between concrete component and the decorator

strategy pattern

a design pattern that enables selecting an algorithm at runtime by defining a family of interchangeable algorithms and encapsulating each one inside a separate class that implements a common interface

state pattern

a design pattern that allows an object to alter its behavior when its internal state changes by delegating behavior to state-specific objects, avoiding complex if-else/switch statements

singpleton

ensure a class has only one instance and provide a global point of access to it

composite pattern

a structural pattern that composes objects into tree structures to represent part-whole hierarchies, allowing clients to treat individual objects and compositions of objects uniformly

software design

• the conception, invention, or contrivance of a scheme for turning a specification for computer software into operational software

• the activity that links requirements to coding and debugging

coupling

describes how tightly a class/method relates to others

design heuristics

1. find real world objects

2. form consistent abstractions

3. enacpsulate implementation details

4. inherit - when inheritance simplfiies the design

5. hide secrets (info hiding)

6. encapsulate what varies

7. strive for loosely coupled designs

8. look for common design patterns

   1. also aim strong cohesion, build hierarchies, formalize class contracts, assign responsibilities, design for test

software process

• a set of related activities that leads to the production of a software product

• basic steps:

  • analysis

  • design

  • implementatio

software process model

a simplified representation of a software process

waterfall model

• sequential, top-down design, bottom-up implementation process

• no feedback loops, no iteration

scrum model

• general agile sw development method w/ a focus on iterative development

  • intial phase: outline planning phase that etablishes general objectives and designs the overall structure architecture

  • series of sprig cycles: each cycle develops an increment of the system

  • closure phase: wraps up, completes documentation, user manuals, and assesses lessons learnt

test driven development

• check out sources and tests from code base

• create test suite / enlarge test suite for product feature, such that current version fails test

• implement functionality and make software pass the test

• refactor software for clarity of design, quality of coding

• make sure that software passes all new and existing tests

• check in software and tests into code base

Functional Specification

defines what a system must do to meet the user's needs. It focuses on the external behavior of the system—how it interacts with users and other systems—without specifying how the code is written internally.

extreme programming (xp)

• an Agile software development methodology that aims to improve software quality and responsiveness to changing customer requirements by advocating for frequent releases in short development cycles

• achieves this through rigorous engineering practices such as test-driven development (TDD), pair programming, continuous integration, and maintaining an on-site customer to provide constant feedback

refactoring

• A series of small steps, each of which changes the program’s internal structure without changing its external behavior

extract method

• observation: a lengthy cluttered method handles a number of problems all on its own

• identify code fragments that can be grouped together

• turn fragment into method

move method

• observation: a method is, or will be, using or used by more features of another class than the class it is defined on

• create a new method with a similar body in the class that uses it the most

• Either turn the old method into a simple delegation or replace calls to the old method by calls to new method; delete old method

Replace Conditional Statement with Polymorphism

• observation: you have a conditional statement that chooses different behavior depending on the type of an object

• move each leg of the conditional to an overriding method in a subclass

• make the original method abstract

form template method

• observation: you have two methods in subclasses that carry out similar steps in the same order, yet the steps are different

• modify each step into methods with the same signature, so that the original methods become the same

• then you can pull them up

software architect

• responsible for high-level design choices related to the overall system structure and behavior

• responsibility: match architectural characteristics with business requirements

software architecture

• defines software system components

• how components use each other’s functionality and data

• how control is managed between components

• Good architecture:

  • high cohesion: measures how closely related the responsibilities are within a single class/module

  • low coupling: measures how dependent one class is on other classes

• large scale

• not about detailed dependencies

• not about classes

• ex: layered, MVC, client/server

layered architecture

• common pattern for overall design of a product

• each layer provides specific functionality

• Closed architecture:

  • each layer can only use services of its layer directly below

  • minimizes dependencies between layers, reduces impact of change

• open architecture:

  • each layer can only use services from some layer below

  • more compact code thanks to direct access

  • breaks encapsulation of layers, increases dependencies

• leads to well defined interfaces between layers