1. CSE 503 – Software Engineering
Lecture 12: Modularity and decomposition
Rob DeLine
5 May 2004

2. Learning about software design
How many of you have had an undergraduate course in...
algorithm selection and analysis?
data structure selection and analysis?
operating systems?
compilers?
software design/software architecture?
Undergraduate CS curricula seldom include a design course
Right now we count on on-the-job training
Imagine if building architects were trained this way!
Imagine if civil engineers were trained this way!

3. Learning about building design
Contrast CS training to architecture training
Undergrads have studio courses, typically every semester
Students are given a “design brief” to fulfill
Students work “en charette” on the design until the jury
(These training projects are sometimes called “charettes”)
Students get feedback through juries
Individuals or teams present their designs
Design consists of drawings and maquettes, presented live
Design is also recorded in a companion written report
Students get feedback from jury committee and each other
Design is a skill learned through experience and feedback

4. 503 Charette The logistics: The brief, in brief:
You have the rest of the quarter to work on a design
You will work in teams of four (no more than 7 total teams)
The jury is during the final exam slot
Each team gets fifteen minutes to present and get feedback
The jury committee will include experienced designers
The brief, in brief:
You will design an and appointment system for a business
A simplified form of Outlook/Exchange or Notes
High availability, cost effective performance
Your design will include
A detailed system architecture
Behavioral models with demonstrated properties
You will get a more detailed brief next Mon 10 May

7. Modularity Why decompose a system?
To divide the work load
The make the system comprehensible
To support reuse
To make the system reasonably testable
To facilitate change of design decisions
What design decisions can we encapsulate?
Encapsulate algorithms with procedural abstraction
Encapsulate data representations with information hiding
Combine these as abstract data types
Any other mechanisms?

8. Basics of information hiding
Modularize based on anticipated change
Minimize dependencies on decisions that are likely to change
Reduces effort in making the change
Separate interfaces from implementations
Implementations capture decisions likely to change
Interfaces capture decisions unlikely to change
Clients dependent on interface, not implementation
Implementation dependent on interface, not clients
Underlying assumptions
The most common anticipated change is about data representation
The effort to make a change is proportional to the dependencies, i.e. the act of change is mechanical or syntactic
How relevant are these assumptions today?

9. Managing dependencies
In theory, a client depends only on an interface
But, what exactly is an interface?
Data types and function signatures?
Ordering constraints and other usage rules of functions?
Asymptotic complexity of functions’ algorithms?
Resource usage of functions?
Implementation policies (client usage assumptions), e.g. caching?
What about when client and implementation run in parallel?
Very complex when client and implementation are from different companies
Need to provide new features in new products
Should also be backward-compatible – whatever that means
For infrastructure, modularity may be a legal matter (MS vs DOJ)