CS 458 - Week 111 Lecture 1 - 2016-11-01

*   Jalote Ch. 6 -- it is all useful/important, BUT!
    ...because of time constraints,
    we'll cover some of these following sections in class, and
    you will be particularly responsible for:
    *   Intro through Section 6.1 - pp. 121-131
        *   important terminology, ideas for judging "goodness" of
            potential designs

    *   Section 6.3, 6.3.1, 6.3.2 - pp. 142-156
        object-oriented design
        concepts [hopefully review?] & UML Intro

    *   Section 6.6 to summary - pp. 172-178
        software metrics & summary 

*   consider high-level software design --
    (this chapter tends to call just design -- )

    *   what modules should the system have?
    *   which modules have to be developed?

    *   (and make sure these modules "fit" with
        the chosen architectural style(s)...)

*   software design can be looked at as having 2 levels:
    *   high-level (software) design 
        *   what modules are needed
	*   deciding on those modules' specifications
	*   deciding on HOW these modules should be
	    interconnected

    *   detailed (software) design/logic design
        *   deciding on the INTERNAL design of these modules
	*   deciding HOW the specifications can be satisfied
        *   expanding the system design to be more detailed,
	    including processing logic and data structures,
	    so that the design is sufficiently complete
	    to proceed to coding

*   design (at all levels) IS a CREATIVE activity;

    ...and design has a GREAT IMPACT on the 
       success of the project! on the coding,
       on the testing, on the maintenance;

*   Key (Software) Design CONCEPTS
    *   the design of a system is CORRECT if...?
        *   it will SATISFY all the requirements, and
        *   it is CONSISTENT with the architecture

    *   of the CORRECT designs,
        we want the "best" -- but what IS the "best"?

	... WITHIN the limitations of the requirements,
	    and the physical and social environment in which
	    the system will operate?

    *   here are some criteria one could use as part of
        trying to determine this (NOT the only ones!!)

	*   modularity
	*   coupling
	*   cohesion
	*   open-closed principle

    *   modularity
        *  a system is considered modular if it
	   *   consists if DISCRETE modules
	   *   such that each can be implemented SEPARATELY
	   *   and a change ot ONE module has
	       MINIMAL impact on other modules

        *   some potential benefits of a modular design?
	    *   enhances design CLARITY
            *   eases implementation
            *   reduces cost of testing, debugging, and maintenance

        *   can't JUST chop a program into random "chunks"
	    to get the benefits of modularity;

            *   would like modules that support a well-defined
	        ABSTRACTION,
		and a clear INTERFACE with which it can interact
		with other modules;

    *   need some CRITERIA for DECOMPOSITION
        *   coupling and cohesion are two such criteria;
	    and the open-closed principle is another (particularly
	    for object-oriented systems)

*   coupling - involved the relationship between
    TWO (or more?) DIFFERENT modules
    *   inter- ! between!

*   cohesion - involves the relationship of the pieces
    WITHIN a module - why ARE those pieces together?!
    *   intra- ! within!

*   coupling -

    *   independent modules - two modules are this if one can
        function COMPLETELY without the presence of the other

        *   not EVERY module can be independent -- there ARE
	    some benefits to careful coupling (superclass/subclasses,
	    anyone?)

	    BUT, when independent - can modify, implement, test
	    separately;

    *   but, modules need to cooperate within a system,
        sometimes code can be saved by having them be related,
	and how do this "well"?

    *   the more connections there are between modules,
        the more dependent they are;
	the more you have to understand ONE module to
	    also understand the other;

    *   COUPLING is attempting to capture this notion,
        of "how strongly" different modules are interconnected;

        *   in general, the more we HAVE to know about a module A
	    to be able to understand a module B,
	    the more closely COUPLED A and B are;

	    *   "highly-coupled" - joined by strong interconnections;
            *   "loosely-coupled" - joined by weak interconnections

	    (independent modules have NO interconnections...)

*   major factors INFLUENCING coupling:
    *   type of connection
    *   complexity of the interface
    *   type of information flow between modules

    *   when pass info via parameters,
        LESS coupled than when using shared global variables
	or shared local variables...!

    *   complexity of the interface - number AND complexity of
        parameters

*   COHESION is WITHIN a single module!
    *   want the things in a module to "BELONG" to that
        module, to belong TOGETHER;

    *   HIGH COHESION is good,
        LOW COHESION is less good;