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