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

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!

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

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 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

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?

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?

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)