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

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: • 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 email 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)