*   cohesion -
    *   intra-modular! WITHIN a module!
    *   why are THESE pieces included WITHIN a
        module?

    *   desired: HIGH cohesion
    *   WANT the elements IN a module
        to be tightly bound, to BELONG together!

    *   ARE many levels of cohesion --
        *   coincidental - NO meaningful relat!
        *   logical - SOME logical relat
            *   functions all in some logical
	        class - e.g., a module
		doing ALL of the inputs
        *   temporal - like logical, except
	        the elements are related in
		time and are executed together;
                e.g., a "cleanup" module,
		an "initialization" module
        *   procedural - elements that belong
	        to a common procedural unit
                (separate a hairy switch into
		its own function...)
        *   communicational - has elements related
	        to a reference to the same input
		or output data
        *   sequential - the elements are
	        together because the output of
		one forms the input of another
        *   functional - considered to be
	        the strongest; all of the
                elements of the module
		are related by performing
		a single function
                
                *   can often be described
		    using a simple, clear
		    sentence
		    (without a lot of
		    ands, etc.)
    *   determining cohesion?
        no hard-and-fast rule,
	BUT it can be useful to try to
        describe the purpose of a module
	in a sentence;

        *   functional? can be described
	    in a simple, clear, specific
	    sentence
        *   compound? more than one verb?
	    probably more than one function --
	    sequential or communicational,
	    maybe?
	*   first? next? after? start?
	    ...these words suggest sequential,
	    temporal
	*   if the predicate does not contain
	    a single specific object following
	    the verb? probably logically 
	    cohesive
	    "edit all data" <- logical
	    "edit source data" <- maybe functional

*   Object-oriented code?
    can consider
    method cohesion - why are THOSE parts
       in A method?
    class cohesion - why are those data fields
       and methods in A class?
    inheritance cohesion - why are these
       classes together in a hierarchy?
       *   hint: BETTER/higher cohesion
           here IF they are together
	   because of generalization/specialization
	   and not JUST code reuse with a weak
	   conceptual relationship

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

        want to be able to add code
	without REQUIRING modification
	of EXISTING code

*   Liskov's substitution principle

*   UML
    *   unified modeling language
    *   a GRAPHICAL language for
        *   visualizing
        *   specifying
	*   constructing
	*   documenting
	...the artifacts of a software-intensive
	system

    *   UML is not ITSELF a model --
        it is a language USEFUL for
	modeling (and more);

        it isn't a software development
	methodology, either;

    *   and, this CAN HELP to understand
        one's system better,
	and CAN HELP in communicating
	aspects of a system;

        it is a NOTATION for representing
	designs at various levels

*   trying to provide "vocabulary" to model
    software at different LEVELS of abstraction