Jalote - Chapter 6 - "Design" - I'd say more
       like Software Design...

*   is the software architecture development/determination
    activity from Chapter 5 a kind of high-level design?
    Perhaps...

*   here, now, in Chapter 6, we are talking about
    system design at the "module" level,
    where the definition of a "module" likely
    depends on the paradigm(s) for the system being
    developed;
    (e.g., function-oriented? object-oriented? etc.)

*   so, at this level of software design,
    we determine:
    *   WHAT modules the system should have [next]
    *   and which have to be developed

    *   often this software design has 2 levels:
        *   high level design/module design
	    *   decide WHAT modules are needed
            *   deciding on the SPECIFICATIONS for
	        those modules 
            *   deciding HOW those modules should be
	        interconnected

        *   detailed design/logic design (logic specified)
            *   decide on the INTERNAL design of
	        the modules
            *   HOW the specifications can be satisfied
	    *   essentially EXPANDS the system design
	        to now be more-detailed;

*   a design methodology - systematic approach
    for creating a design,
    by applying a set of techniques and guidelines

*   key software design concepts
    *   FIRST: the design of a system is correct if
        *   it will satisfy all the requirements and
	*   it is consistent with its architecture

    *   there can be more than one design that
        meets these particular correctness
	criteria --
	how can we determine which of these is
	"best", or at least, between several,
	which is "better"?

    *   here are 4 possible criteria we could use
        in trying to assess the "better"-ness of
	different potential designs:

        *   modularity
        *   coupling
        *   cohesion
        *   open-closed principle

   *   modularity
       *   a system is considered modular if it consists
           of discrete modules,
	   such that each can be implemented separately,
	   and a change to one module has minimal
	      impact on other modules

       *   a design with a higher degree of modularity
           will likely be more clear,
	   likely be easier to implement,
	   likely/potentially less expensive to
	      test/debug/maintain;

       *   you can't JUST randomly/arbitrarily
           chop a task into pieces and get
	   "good" modularity, however;

           ...we'd like each module to support a 
	   well-defined abstraction; 
           ...we'd like a clear interface through which
	   it can interact with other modules;

           ...need some criteria for decomposition!
           *   SUCH AS...for example!
	       coupling;
	       cohesion;
	       the open-closed principle;

Coupling!
*   is BETWEEN modules
*   consider first the concept of independence
    *   two modules are independent if one
        can function COMPLETELY without the
	presence of the other

    *   there are benefits to independence!
        *   modules can be modified separately,
	    implemented and test separately,
	    could help decrease programming/development
	    costs;

*   do you see that MORE connections there are
    between modules -- the more dependent they
    will be on one another?

*   coupling tries to capture this notion
    of "how strongly" different modules are
    interconnected;
    *   "highly-coupled" modules have "strong"
        interconnections;
    *   "loosely-coupled" modules have "weak"
        interconnections;
    *   (and INDEPENDENT modules have NO interconnections);

...SO: we WOULD like LOOSELY COUPLED modules;
*   major factors influencing coupling:
    *   type of connection between modules
    *   complexity of the interface
    *   type of information flow between modules

    (we'd like the interface of a module to be
    small, simple, obvious/apparent;)

Cohesion!
*   is WITHIN a module
*   what are the connections between the parts
    WITHIN a single module?

*   how tightly bound the element within a module
    	are;
    you'd like HIGH cohesion -- you'd like
    those things that are there to be there
    for a good reason!