WEEK 1 .
Lecture 1: Introduction, Functional Decomposition
- Product: machine-executable `working' program or component
- Product documentation: artifacts to support product (design)
- Process: the way persons work (individually, or as a team)
- Process documentation: describes/prescribes a process
- Technique: `Divide and Conquer'
o Split problem into subproblems ( Decomposition)
o Solve subproblems independently ( Recursion possible)
o Combine subproblem solutions into total solution ( Integration )
- Precondition: Predicate in terms of global variables and parameters
- Postcondition: Predicate in terms of global variables and parameters
o \old(v) denotes value of v on entry
o Typically used for procedures, not for functions, but can involve pseudo-variable \result
- Returns: Function of global variables and parameters – typically used for functions
- Contract species which problem is solved, by precondition and postcondition
o User doesn’t need to know how the problem is solved
o Provider doesn’t need to know what the solution is used for
Lecture 2: Decomposition, Testing, Design Patterns
- Abstract = to ignore/ suppress what is considered irrelevant
- Abstract from how a subproblem is solved, through a speciation.
- Abstract from which subproblem is solved, through parameters.
- Abstract from how a solution is used, through a speciation.
- Thinking in terms of dependencies is key (A depends on B so if B changes so should A but not wise versa)
- Advantages of divide and conquer
o Gives solution of more complex problems
o Organizes communication about solution domain
o Facilitates parallel construction by a team
o Improves ability to plan work and track progress
o Improves ability to work together – review design, unit testing, stepwise integration
o Improves so that changes affect few components
o Improves possibilities for reuse
- Disadvantages of divide and conquer
o Top level divisions are hard to make
o Separation often brings overhead
o Result looks bigger but has explicit structure
o Functions cant be specified/designed/implemented in isolation – considered in related groups
- Guidelines for Functional Decomposition
o Maximize cohesion (what belongs together goes together)
o Minimize coupling (measure of connectedness between modules), so minimized dependency
o Each function should solve a single well defined problem
o Limit the size of the interface, so not pass unnecessary data
o Each problem solved in one place – don’t repeat yourself
o Avoid code replication
o No more that few dozen lines with limited nesting depth
o Cyclomatic complexity is a good metric – if more than 8 should consider a sub division
- Generalization
o Solving a more general problem than required – improves reusability
o Generalize by means of parameters not global variables
o Decomposing a problem into simpler versions of itself gives tise to recursion
- Failure : product deviates from requirements during use/operation
- Defect: product can somehow lead to failure
o Decrease predictability
o Concern risks – uncertainty
, o Increases with higher system complexity
o Detecting = Reviewing and Testing, Removing Defects = Testing and Debugging
- Mistake: human action causing a fault
o Misunderstandings
o Overlooking a case in requirements
o Having incorrect algorithm
o Ty[ping error
o Making an unwanted assumption
o Dealing
Admit, prevent, minimize consequences, detect presence, localize defects, repair, trace,
learn from them
- Error : difference between actual and specified/expected result
- Test cases
o Black-box, or test-to-specifications, or functional – tests functionality
o Glass-box, or test-to-code, or structural – tests internal logic
- A Design Pattern is an outline of a general solution to a design
- problem, reusable in multiple, diverse, specific contexts.
Chapter 4: Programming in the Large I – Subroutines
4.1 Black Boxes
- Subroutines help with complexity
- Referred to as black boxes
- Inside of the black box is implementation
- Rules of black boxes:
o The interface of a black box should be straightforward, well-defined, and easy to understand.
o To use a black box, you shouldn't need to know anything about its implementation; all you need to know
is its interface. (should be able to change the implementation of the box if the behavior seen from
outside is the same).
o The implementor of a black box should not need to know anything about the larger systems in which the
box will be used.
- Interface also includes a specification of what the box does and how it can be controlled - interface of a subroutine
has a semantic as well as a syntactic component.
- Syntactic part of the interface tells you just what you have to type in order to call the subroutine
- Semantic component specifies exactly what task the subroutine will accomplish
- Syntactic and semantic -- collectively as the contract of the subroutine
- Comments that you write for the subroutine should make the contract very clear
- Subroutines are not the only example of black boxes in programming
4.2 Static Subroutines and Static Variables
- Every subroutine in java must be defined inside some class
- Static vs non-static subroutines
o A static subroutine is a member of the class itself.
o Non-static subroutines only become relevant when you are working with objects.
- Subroutines = method
- Body of subroutine = the statements within the { … }
- Modifier = such as static/public/etc. before the method name
- Void = no value is returned
- Parameter list = method something( int paremeter_1, double parameter_2), where int and double are type
parameter names
- Subroutine-name(parameters); if the subroutine that is being called is in the same class.
- class-name. Subroutine-name(parameters); if the subroutine is defined elsewhere, in a different class.
- Local variables = declared inside subroutines
- Global variables = declared inside the class
- When you declare a local variable in a subroutine, you have to assign a value to that variable before you can do
anything with it
- Member variables, on the other hand are automatically initialized with a default value.
, 4.3 Parameters
- Parameters in a subroutine definition are called formal parameters or dummy parameters ( like a name )
- The parameters that are passed to a subroutine when it is called are called actual parameters or arguments (
like a value )
- Signature of subroutine = knowing the name of it and the type of parameters it has
- Overloading = having subroutines with the same name, but different parameter. If have same parameters but
different return types would not work.
- If the caller violates the contract by passing an invalid string as the actual parameter, the subroutine responds
by throwing an exception of type NumberFormatException.
- IllegalArgumentExceptions in response to bad parameter values.
o throw new IllegalArgumentException( error-message );
o static void print3NSequence(int startingValue) {
o
o if (startingValue <= 0) // The contract is violated!
o throw new IllegalArgumentException( "Starting value must be positive." );
o .
o . // (The rest of the subroutine is the same as before.)
- Javadoc comment must be placed just before the subroutine that it is commenting on
- If comment will contain only basic information such as the name and type of a member variable or the name,
return type, and parameter list of a subroutine = syntactic information
- Doc tags for Javadoc
o @param parameter-name description-of-parameter
o
o @return description-of-return-value
o
o @throws exception-class-name description-of-exception
- static import
o import static package-name.class-name.static-member-name;
- convenient way to express the contract of a subroutine is in terms of preconditions (something that must be true
when the subroutine is called) and postconditions (something that will be true after the subroutine has run).
- public class Bank {
o private static double interestRate;
o interestRate = 0.05; // ILLEGAL:
o . // Can't be outside a subroutine!:
- "final" can be applied to a variable declaration to ensure that the value stored in the variable cannot be changed
after the variable has been initialized
- The portion of the program source code where the variable is valid is called the scope of the variable.
Programming in the Large with Design Patterns Chapter 1: Introduction to Design Patterns
- Facade defines a higher-level interface that makes the subsystem easier to use.
- Important characteristics of patterns:
o design (and more generally engineering) is about balancing conflicting forces or constraints.
o design patterns provide general solutions (not exact solutions)
o designs can’t be generalized to all situations/cases
- A software design pattern is a reusable solution to a reoccurring software design problem. A design pattern
provides a mapping from a specific design problem to a generic solution.
- Four main categories of software patterns are: analysis patterns, architectural patterns, design patterns and
programming idioms.
- Architectural Patterns:
o At the architectural level, components are programs and subsystems – Programming Idioms – “recipe” so
platforms (like Java) contain “cookbooks” of simple functions available.
o For mid-level design, components are classes and objects – Design Patterns.
o Architectural Pattern - high-level plan for organizing the top-level components of a program or software
system.
- Algorithms are not design patterns:
