Show Menu
Cheatography
  1. Home >
  2. Programming >

cs2340_exam2 Cheat Sheet (DRAFT) by

exam 2 cheat sheet for cs2340

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Test-D­riven Develo­pment

Failure vs Fault vs Error
 
Failure
Observable incorrect behavior, ex. a+b vs a*b
 
Fault (bug):
Related to the code. Failure IFF fault
 
Error
Cause of a fault. Usually human error (conce­ptual, typo, etc.)
Verifi­cation
Testing (test cases), Static Verifi­cation (all possible inputs), Inspec­tio­n/r­evi­ew/­wal­kth­rough, Formal proof
Granul­arity:
Unit Testing -> Integr­ation Testing -> System testing -> Acceptance testing -> Regression testing
within org
Developers testing -> Alpha testing
outside org: Beta testing -> Product release
what is tdd
Write tests -> write functional code -> refactor
"Make it Fail, Make it Work, Make it Better­"
Why TDD
Provides increm­ental specif­ica­tion, avoid regression errors
Structure of tests
Set fixture, invoke, check, cleanup

Teamwork Consid­era­tions

People are most important asset
Critical factors in people management
Consis­tency, respect, inclusion
Factors influe­ncing team working
Group compos­ition, Group cohesi­veness, Group commun­ica­tions, Group organi­zation
 
Group compos­ition
Task-o­rie­nted, self-o­rie­nted, intera­cti­on-­ori­ented
Hitchh­iker:
Take credit for team's work w/o contri­buting
Couch potato
Willing to work, but drag their feet
Absorbing leads to couch potatoes / hitchh­ikers
- Mirroring reflects conseq­uences onto hitchh­ikers

Sequence Robustness

GUI prototype -> Code
Dynamic
Static
 
Use Case Model -> Robustness diagram -> Sequence Diagram
Domain Model -> Class Diagram
Robustness diagrams bridge the "­wha­t/h­ow" gap
Notation
 
Boundary Class
a user interface or API class to external system
 
Entity Class
a class from the domain model
 
Controller Class
a class repres­enting business logic or logical software function
Valid relati­onships
Nouns<­->V­erbs, Verbs<­->Verbs
Nouns!­->nouns
 
valid ex: Actor-­>Bo­undary, Bounda­ry<­->C­ont­roller, entity­->c­ont­roller
 
invalid ex: actor-­>co­ntr­oll­er/­entity, bounda­ry-­>en­tity, entity­<->­entity, bounda­ry<­->b­oundary
Robustness analysis guidel­ines:
 
Make a boundary object for each screen & name them well
 
Usually not real controller objects, but rather logical software functions
 
Direction of arrows not important
 
Bounda­ry/­entity classes -> object instances, contro­llers -> messages
Sequence Diagrams
 
SD shows how objects within system interact
SSD shows how actors interact w system

Design Class Diagrams

Domain model shows real-world concepts, DCD shows software entities
Class attributes
 
Full format
visibility name : type multip­licity = default {prope­rty­-st­ring}
 
Visibility marks
+ (public), - (private), # (prote­cted)
 
Attributes assumed private if no visibility is given
 
Operations assumed public if no visibility is given
Attrib­ution text vs associ­ation line
 
[IMAGE HERE]
 
Guideline
Use the attribute text notation for data type objects and the associ­ation line notation for others
Two ways to show collection attributes
 
[IMAGE HERE]
Note symbol: can represent UML note or comment, UML constr­aint, or Method body
Operations and Methods:
 
Operation syntax, UML1:
visibility name (param­ete­r-list) : return­-type = default {prope­rty­-st­ring}
 
Operations are usually assumed public if no visibility is shown
 
Operations to access attributes are often excluded
UML keywords:
 
«actor»:
classifier is an actor, ex: in class diagram, above classifier name
 
«inter­face»
classifier is an interface, ex: in class diagram, above classifier name
 
{abstract}
abstract element; can't be instan­tiated, ex: in class diagrams, after classifier name or operation name
 
{ordered}
a set of objects have some imposed order, ex: in class diagrams, at an associ­ation end
Depend­ency:
 
[IMAGE HERE]
 
dependency labels are optional
ex: <<c­all­>> and <<c­rea­te>>
Interf­aces, Inheri­tance, Abstract class, Compos­ition, Aggreg­ation
 
[IMAGE HERE]
 
Aggreg­ation
“has-part” associ­ation relati­onship, exists w/o parent
 
Compos­ition
whole-part associ­ation relati­onship, needs parent to exist
Constr­aints (3 ways)
 
[IMAGE HERE]
Utility class
 
[CODE HERE]
 

Mapping designs to code

Class-­Res­pon­sib­ili­ty-­Col­lab­oration (CRC)
Brains­torming tool used in OOD. CRC cards are usually created from index cards.
CRUFT
useless, redundant, or poorly written code
Don’t Repeat Yourself (DRY)
Every piece of knowledge must have a single, unambi­guous, author­itative repres­ent­ation within a system
Separation of concerns (SOC)
 
Design principle for separating a computer
 
Concern is a set of inform­ation that affects the code of a computer program
You Aren’t Gonna Need It (YAGNI)
 
A programmer should not add functi­onality until deemed necessary
 
"do the simplest thing that could possibly work”
 
Must be used in combin­ation with several other practices, such as continuous refact­oring, unit testing and continuous integr­ation
Collection Classes:
One-to­-many relati­onships are common.
E.g., a Sale must maintain visibility to a group of many SalesL­ineItem instances

Object visibility

Visibility
the ability of one object to see or have reference to another
Attribute visibi­lity: B is an attribute of A
 
Relatively permanent visibility
 
Common form of visibility in OO systems
Parameter visibi­lity: B is a parameter of a method in A
 
Relatively temporary visibility
 
Common to transform parameter visibility into attribute visibility
Local visibi­lity: B is a (non-p­ara­meter) local object in a method of A
 
Relatively temporary visibility
 
Two methods:
- Create a new local instance and assign it to a local variable.
   
- Assign the returning object from a method invocation to a local variable.
Global visibi­lity: B is globally visible
 
Preferred method to achieve global visibility is to use the Singleton pattern.

Code smells

code smell
quick-­to-spot surface indication that something is wrong with your code
usually found during examining & refact­oring
usually caused by rushed design and a disregard for technical debt
 
technical debt
the amount of work you create when you try to save time upfront
 
right way vs fast way
Types
 
Bloaters
long method, large class, long parameter list (>=­3,4), data clumps (ex: RGB always together)
 
Object­-Or­ien­tation Abusers
Switch statem­ents, Refused Bequest (inherit methods but unused or redefined)
 
Change Preventers
   
Divergent Change (many changes to single class from copy-p­aste)
   
Shotgun surgery (many small changes to many classes from too much coupling, too little cohesion)
 
Dispen­sables
Lazy class (doesn't do enough), Data class (only fields + getter­s/s­ett­ers), Duplicated code
 
Couplers
   
Feature envy
A method that seems more interested in a class other than the one it is in
   
Inappr­opriate intimacy
Classes know too much about each other's private parts (tightly coupled)
   
Middle man:
class performs one action delegating work to other class

Respon­sib­ili­ty-­driven design

respon­sib­ility
Obligation to perform a task or know inform­ation
Behavior (doing) vs data (knowing)
Methods vs respon­sib­ilities
methods fulfill respon­sib­ilities
 
Respon­sib­ilities are implem­ented by means of methods that either act alone or collab­orate with other methods and objects
 

GRASP: [spell out]

Who is respon­sible for creating a new instance of a class?
 
Rules: Assign class B to create class A if:
   
B contains or aggregates A
   
B records A
   
B closely uses A
   
B has the initia­lizing data for A (B is an Expert with respect to creating A)
 
If >1 option, prefer aggreg­ation
1. Creator -> Low coupling:
 
Guideline 1
A composite object is an excellent candidate to make its parts
 
Guideline 2
Look at the class that has the initia­lizing data
   
E.g., a Payment instance must be initia­lized with the Sale total. Hence, Sale is a candidate creator of Payment
 
Guideline 3
In case of complex rules consider delegation of creation to a helper class
2. Inform­ation Expert -> Low coupling, high cohesion, reduce feature envy
 
Assign a respon­sib­ility to the class that has the inform­ation necessary to fulfill the respon­sib­ility
 
Many “partial” inform­ation experts may collab­orate in a task
3. Low Coupling
Assign respon­sib­ilities so that coupling remains as low as possible.
 
High to low:
   
***Content coupling: one class modifies another (branch into middle of routine, modifies code)
   
**Common coupling: share common (global) data
   
**Control coupling: use a method parameter (by passing some kind of flag) to control a different method
   
Stamp/Data coupling: passing complex data or structures between module­s(& use primitives when possible)
   
Uncoupled: no relati­onship
   
*** DO NOT DO THIS!!!
   
** TRY HARD NOT TO DO THIS!
 
Common forms of coupling:
   
TypeX has an attribute that refers to TypeY
   
TypeX calls on services of TypeY
   
TypeX has a method that refers to TypeY
   
TypeX is a subclass of TypeY
   
TypeY is an interface and TypeX implements it
4. Controller
 
UI objects should not have respon­sib­ility for fulfilling system events
 
Delegates work to other objects & coordinate / control the activity
 
Assign respon­sib­ility to a class that:
   
Represents the overall System ( Façade Controller )
   
Represents a Use Case scenario where the event occurs (<u­secase name>H­andler, <uc­n>C­oor­din­ator, <uc­n>S­ession)
5. High Cohesion: Objects should not do many unrelated things
 
High to low
   
***Coi­nci­dental: unrelated functions
   
Logical: multiple logic sections
   
Temporal: related by phases of an operation
   
Proced­ural: required ordering of tasks (addIn­gre­dients, mix, bake)
   
Commun­ica­tional: operates on same data set
   
Functi­onal: all essential elements for a single function are in same module (takeOff, fly, land)
   
*** DO NOT DO THIS UNLESS UNAVOI­DABLE!!
Refact­oring:
 
Goal: Keep program readable, unders­tan­dable, and mainta­inable
 
Preserve behavior by using tests
Ex: rename, extract method, move method, replace temp w query

SOLID: [spell out]

S: Single Respon­sib­ility Principle
 
Each class should have a single overriding respon­sib­ility (High Cohesion) -> many small classes > one big class
 
Each class has one reason why it should change
O: Open/C­losed Principle
 
Objects are open for extension but closed for modifi­cation
 
Extension via inheri­tance, polymo­rphism
L: Liskov Substi­tution Principle
 
Subclasses should be substi­tutable for their base classes
 
class that implements an interface must be able to substitute any reference throughout the code that implements the same interface
I: Interface Segreg­ation Principle
 
Use several small interfaces vs one larger multip­urpose one
 
Don’t make clients depend on interfaces they don’t use (Athlete -> Swimmi­ngA­thlete, Jumpin­gAt­hlete)
D: Dependency Inversion Principle
 
High-level modules should not depend on low-level modules. Both should depend on abstra­ctions.
 
Abstra­ctions should not depend on details. Details should depend on abstra­ctions (write­Java; writeJ­ava­Script -> develop() calls writeJava, writeJ­ava­Script)
ISP vs LSP
ISP: parent <-> client
LSP: parent <-> child