Download
1 / 8
80 likes | 190 Vues
Begin with initial design, receive sponsor feedback early, create end-to-end working systems, define information exchange interfaces, work on system layers independently, write interface stubs, validate architecture with proof of concept.
E N D
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.
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.
System with Four Major Layers Client Server Business Rules Data Access Layer Database
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.
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
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.
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.
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.
