Some initial Design suggestions…

1. Some initial Design suggestions… • Getting started… where to begin? • Find out whether your design architecture will work… as soon as possible. • If you need to make changes to the initial design… better sooner rather than later. • You need sponsor feedback on the usability of your design as soon as possible.

2. Create an End-to-End Working System • System components created as “hollow” objects. • Client, web server, and database layer • Initially the objects do no work. • Login accepts a single user name and generates a valid login. • Database access layer returns canned data, not data from the database • Define the information that the objects need to exchange and document these interfaces with method signatures. • Now each object can be assigned to a different set of team members. • Write enough code to make everything look as if it works.

3. System with Four Major Layers Client Server Business Rules Data Access Layer Database

4. Each Layer is worked on independently • Assume each layer exists on a different computer – with all communication over the network. • No one can access the code of another layer directly. • Architecture is scalable … e.g. if a layer requires more resources, you could conceivably move to a larger machine.

5. Write Interface Stubs • Keep it simple – the goal of the interface is to be just thin enough to compile and be used. • Examples: Boolean Login (String userName, String passWord) { return true; } DataSet AnalyzeDataSet (DataSet thisDataSet) { DataSet thatDataSet = new DataSet( ); thatDataSeet.add(2); thatDataSeet.add(3); thatDataSeet.add(5); return thatDataSet; } These are routines that a client can invoke and use

6. Make sure the “hollow” shell works… The goal… • Complete, documented, architecture. • Proof of Concept that shows the designed architecture works. • You can see a client request run, end-to-end. • You have a design prototype! • Clear boundaries defined for work assignments. • Functionality has been encapsulated. • Team interaction is facilitated with the need to talk about “adjacent” code.

7. Adding Detail • Trying to define all the detail at the beginning is time consuming and delays finding out whether the design as a whole will work. • Adding the functionality will take time… make sure the hollow shell works end to end before implementing the real “stuff”. • When you start adding detail… solve the hardest problems first. Making Login work first is a mistake.

8. Effective Design Meetings?? • One team member leads the meeting… maintains order and focus… keeps a speaker list. • Notes should be recorded on a white board… everyone must be able to see method signatures as they are discussed and agreed upon. • Record the interfaces and “publish” them so everyone knows!! • Hold meetings where you will not be interrupted.