CS 435 - Week 12 Lecture 1 - 2014-04-15

a few points with regard to coupling:
*   major factors influencing coupling:
    *   type of connection between modules
    *   complexity of the interface
    *   type of information flow between modules
        *   here, type: for data, or for control

        *   if you are transferring control
	    information,
	    the action of module DEPENDS on that
	    information,
	    *   CAN make modules more difficult
	        to understand

        *   if you are transferring data
	    information, module is more likely
	    to be able to be treated as
	    input/output function;

	    lowest coupling: interfaces with
	    only data communication

            highest coupling: hybrid interfaces;
	      combination of some data items
	      and some control items passed
	      between modules, CAN be more
	      confusing

*   note Chapter 6 also goes in more depth
    about some particular-to-OO-systems
    coupling considerations;
    *   interaction coupling - methods of a
        class invoking methods of other classes
        *   bad if methods change internal data
	    of other methods --
	    better if methods JUST communicate
	    via parameters!

        *   better, too, if fewer simpler parameters
	    than when more, more complex parameters

    *   component coupling -when a class A has 
        variables of another class C
        *   weakest/loosest/most desirable
	    when the variables of class C are
            either in method signatures or
	    are attributes/data fields of class A
	    (e.g., NOT buried as local variables
	    within methods)
  
    *   inheritance coupling - two classes are
        inheritance coupled if one is a subclass
	or descendant of the other

*   Cohesion - talking about WITHIN a module;
    why are the things within this module here?
    *   high cohesion is good -- these things
        are in a module because they BELONG
	together!
    *   see the levels of cohesion discussed
        in the chapter!

    *   in OO systems in particular...
        method cohesion - why are these code elements
	    within a particular method?
        class cohesion  - why are these methods and
	    data fields together in this class?
	inheritance cohesion - why are classes 
	    together in a hierarchy

*   2 main reasons for subclassing/inheritance:
    *   generalization/specialization  <-- cohesion
					   tends to be
					   higher
    *   code reuse
 
    ^ might have both! BUT sometimes one is tempted
      to subclass to share code that actually
      has a weak conceptual relationship;

*   open-closed principle   
    *   a module should be open for extension 
        but closed for modification

*   Liskov's substitution principle -
    *   IF inheritance hierarchies are built
        in a manner supporting the open-closed
	principle, they are said to satisfy
	this;

        Principle: If a program is using an object
	   o1 of (base) class C,

	   that program should remain UNCHANGED
	   if o1 is replaced by an object o2
	   of a subclass of C

UML !!
*   Unified Modeling Language

    *   yes, it is a language!
        ...a *graphical* language;

    *   it is a language for specifying,
        not a method or procedure;

*   there are MANY UML diagram types,
    to ALLOW for modeling at different levels
    of abstraction;

    UML 2.0 defines 13 types of diagrams;
    *   one reference divides these into
        3 categories:
	*   structure
            *   class diagram
            *   object diagram 
            *   component
            *   package
            *   deployment 
	*   behavior
            *   use case diagram 
            *   activity
            *   state machine diagram 
	*   interaction    
            *   sequence diagram
	    *   communication
	    *   timing diagram
            *   interaction overview