Nov. 6, 2013
cs561 Software Engineering Notes

Previously we discussed Cohesion and Coupling

Cohesion = stickiness, adherence, things that go together
Want to increase software cohesion

Functional - code/methods/classes that perform only one computation are kept 
together and perform no side effects
Layer - related services are kept together.  all other services are kept out.  
Have a hierarchy that is strictly enforced where high level services access 
only lower level services
Communicational - keep code working on the same data together (ex. good class 
design)
Sequential - procedures working on the same computation kept together.  Use 
output of one procedure as input to the next procedure
Procedural - procedures called one after the other are kept together
Temporal - procedures use in same general time frame are kept together (e.g. 
initialization, finalization)
Utility - Keep related utilities together

Coupling - interdependencies between one module and another

Content coupling - a component such as a class directly modifies data/DS 
internal to another component (esp. in a sneaky way)

Line1 has get start/get end
Line2

Point (has get and set methods)

Assume line is immutable
pull data from line (e.g. get start) use a set method to change value in point 
thus changing the line (which is immutable)

Common coupling - using global variables (common is from Fortran)

Control coupling - a procedure directly controls another (e.g. by using a flag)

Stamp coupling - a method contains arguments of the type of an application 
class (make simpler if possible)

Data coupling - method contains simple data type arguments (replace with a 
class if appropriate)

Routine call - a method calls another method (try to reduce this if possible)  
method calls cost lots of time

type use - reduce usage of globally defined data types

Inclusion or import coupling - too many import statements

External - code is dependent upon something outside of the system (e.g. OS, 
libraries, etc.) don't use if not necessary


Design principles

1. Divide and Conquer
2. Increase cohesion
3. Decrease coupling
4. Keep abstraction high
	E.g. top-down design - use class models without variables initially
	dynamic binding (what is it?) think calling methods from interface
	default values
5. Increase reusability
	Simplify design
	Use hooks (remember hooks and slots)
6. Reuse existing design and code where possible
7. Design for adaptability
	Don't hard code values - no magic numbers
8. Anticipate Obsolescence
	use common libraries and latest releases
	use standard technology where possible
9. Design for portability
	use a portable programming language (i.e. don't program in assembly 
        unless absolutely necessary)
10. Design for testability
both automatic (e.g. using redirection) and manual (debug print switch/common 
output)

11. Defensive design
	trying to ensure there aren't faults in code
	Use design by contract
		Preconditions
		Postconditions
		Invariants (don't change when a method executes)

		All are boolean expressions
		All can be expressed in a formal constraint language (e.g. OCL)

		Use assertions
			assert( some boolean expression )
			keyword in most languages
			if assertion is false program ends immediately

Techniques to make good design decisions
	Consider existing priorities and objectives for quality
	Consider memory and CPU efficiency
		maintainbaility, portability , usability
	
	List design decision alternatives
	list advantages and disadvantages of alternatives
	Does an alternative prevent you from meeting an objective
	Choose alternative that best meets objectives
	Adjust priorities as necessary

Cost-benefit analysis
	Want to reduce costs and increase benefits
	Often taught in management
	SW Eng Work
		maintenance for life of system
		cost of doing requirements, design, implementation, QA
		time measured in person days or person months
		cost = salary + office space + travel + other costs
	Development technology
	End-user support and product support personnel
	Time saved by doing proper design
	Benefits of increased sales

Next time - Model driven development
Software architecture models, architectural patterns, and component models