What's the core problem in software design? 

Decomposing systems into modules.

Why do we have to do this? 


Real systems are 
--<large>, and they are <complex>
--we have to get them done in a reasonable amount of time. <tight schedules> 
--and we have to be evolve them to meet new requirements. <system evolution> 
--The construction process is not always monolithic        <compositional structure>
    -it can be broken up over time (one piece now, once pice later, then assemble)
    -and can be broken in space (One piece in Israel, one piece in UK, etc). 

These issues drive modularization.

Dealing with size

---systems are too large for one person to <build>.
   (so we need to separate them into modules, for
    task decomposition)
---Systems are too large for any one person to even
   <<understand>>
   (so we need knowledge or expertise specialization).


Dealing with schedule constraints. 
 
---If modules are relatively independent, we can
   give different people the task of building different
   sub-modules, and this makes it possible to develop
   large systems faster, "in parallel". 

---what's required for this "parallelization" to work
   properly. 

---What if we did this without knowledge decomposition? 
   (won't work! requires n^2 communication)

Principle: modules must "encapsulate knowledge" (each module
           captures all the relevant data and logic of particular
            type) 


Principle: Modules must have rules/conventions of
           interaction, called "design rules" 


Dealing with evolution 

Suppose you have to deal with a new requirement, or a requirement
gets changed.

---What if the change affects many modules? 

--What if the change affects only one module? 

--What if the affected module strongliy interacts with
  other modules? 

---What does this say about mapping requirements to modules? 

Principle: separation of concerns (each piece of variable requirements
           maps, as much as possible to one module) 

Principle:  Information Hiding. (modules have secrets, that allow
            them to vary indendently) 
 
Principle:  Low coupling  (modules are not highly dependent on each other)


Summary of principles (order of importance)

---Separation of concerns (recap)

---Enscapsulation (recap)

---"Laws of Interaction" or design rules.

---Information Hiding. 

---Low coupling

Other important desiderata of modules

---abstraction  (modules should be as general as possible, e.g.,
                 C++ templates) 

---Cohesion.  (all the bits of a module really belong together)

---Reusability  (Modules are flexible & robust and admit different
                 uses)


--Different types of modules based on time-of-composition. 
   > Modularity of manufacture (e.g., car parts)
   > modularity of use (e.g., keyboards, mouse, monitor, etc). 
   > Examples of each in Software?  


--Finally: what is a module? 

 > For a Turing machine? 
 >in assembly language? 
 > For C? 
 > For Java
 > For C++



What features in C++ and Java help: 

---Seperation of Concerns? 

---Information Hiding? 

---Abstraction? 

---Reduced coupling? what features make coupling worse? 

--modularity of manufacture? 

---modularity of use?