the cos 333 project - cs.princeton.edu · 4 three-tier systems examples: many web-based services...
TRANSCRIPT
2
Overview
A simulation of reality In groups of 3-5 people... Build a substantial three tier software
system
3
Three-Tier Systems
"Three tier" system
1.User interface (usually graphical)
2.Storage/data management (usually database)
3.Processing in the middle ("business logic")
4
Three-Tier Systems
Examples: Many web-based services Amazon, Ebay, other web stores News, information services, bots, mashups Email, chat, search, code tools, maps, ... Many smart phone systems
Your system should be similar But smaller, simpler, defined by your interests
or the needs of others
5
Decisions
User interface Browser, desktop, phone, API, ... HTML/CSS, JavaScript, jQuery, Flash, Java
Applets, ...
Main language(s) Java, Python, C, C++, C#, Perl, PHP, Ruby,
Objective C, ...
Server CS, OIT, your own computer, Google App
Engine, hosting service, …
6
Decisions
Database MySQL, SQLite, Postgres, flat files, ...
Data exchange formats text, XML, JSON, REST/Atom, ...
Development tools and frameworks Django, Rails, Google Web Toolkit, XCode,
Eclipse, Visual Studio, ...
7
Decision Making Strategies
Do informal thinking and exploring early So you have time to let ideas gel
Do many simple experiments early So you learn what works or doesn't
Make "large grain" decisions before "small grain" decisions
8
Decision Making Strategies
Think about risks What could go wrong? What are you dependent on that might not
work out?
9
Getting Started
Right now, if not sooner! Think about potential projects
Talk to course instructors Look at previous projects Check out the external project ideas page Look around you
Form a team OK to use the listserv for match-making
10
Deliverables
All are graded See "Schedule" Web page for due dates First deliverable
Initial meeting with lead instructor To be sure your project idea is generally ok You should have one pretty firm consensus
idea, not several vague ones
11
Deliverables
Early-project deliverables: Initial Web site Elevator speech Project overview document
12
Deliverables
Mid-project deliverables: Project timeline document
Updated weekly Weekly status meetings
Attendance mandatory Be prepared to describe what you
accomplished, what you didn't, what you plan to do next
13
Deliverables
Late-project deliverables: Demonstration of prototype Demonstration of alpha version Demonstration of beta version Presentation and final demonstration (Continued on next slide)
14
Deliverables
Late-project deliverables (cont.) Final Web site User's guide document Design document Compressed source code file Final report document Working system
15
Process
Use an orderly process This is NOT a process:
Talk about the software at dinner Hack some code together Test it a bit Do some debugging Fix the obvious bugs Repeat until the semester ends
16
Process
Classic "waterfall" model Overkill for 333, but some process is essential
specification requirements architectural design detailed design coding integration testing delivery
17
An Informal Process
Step 0: Choose a leader Goal: Make system work like the product of a
single mind but with multiple developers Implication: Everyone has to pull together;
someone has to be in charge Successful software development projects
are not democracies
18
An Informal Process
Step 1: Determine requirements (who) Who are the users? Decide what user need(s) will the system
fulfill? Involve users, if possible
Conduct interviews
19
An Informal Process
Step 2: Determine functionality (what) What should the system do? Create scenarios
Blackboard sketches, screens, story boards
Low fidelity early; maybe high fidelity later Involve users, if possible
Show scenarios
20
An Informal Process
Step 3: Determine design (how) How will the system work? Decide pervasive design issues: languages,
dev environment, database, … Resolve issues of connectivity, access to
information, software, etc. Partition into major subsystems Specify interfaces between subsystems Make "build versus buy" decisions
21
An Informal Process
Step 4: Code Involve all team members
Every team member must do a significant part of the coding
Code in stages Do not build something that requires a "big
bang" where nothing works until everything works
Always be able to declare success and walk away
22
An Informal Process
Step 5: Test Integrated with Code step
Make sure it always works Fix bugs before adding features
Additional distinct step at the end Involve users, if possible
23
An Informal Process
Step 6: Document Integrated with previous steps Additional distinct step at the end Internal doc, Web page, presentation, final
report, …
24
Process Suggestions
Count on iteration Try to revisit requirements, functionality,
design infrequently Iterate between coding and testing frequently
25
Process Suggestions
Use version code control system for everything CVS or Subversion or equivalent is
mandatory
26
An Informal Process
Leave lots of room for "overhead" activities Testing: build quality in from the beginning Documentation: you have to provide written
material Deliverables: you have to package your
system for delivery (Continued on next slide)
27
An Informal Process
Leave lots of room for "overhead" activities (cont.) Changing your mind: decisions will be
reversed and work will be redone Disaster: lost files, broken hardware,
overloaded systems, ... Sickness: you will lose time for unavoidable
reasons Health: there is more to life than this project!
28
Design: Interfaces
Interface The "public" part of a module A module's "advertisement" to clients A module's contract with clients
What are the inputs? What is the transformation? What are the outputs? Who manages resources? Who detects/reports errors?
29
Design: Interfaces
Suggestion: Hide design & implementation decisions behind interfaces So they can be changed later without affecting
the rest of the program Database system, data representations, file
formats Algorithms Visual appearance
30
Design: Interfaces
Common comment: "I wish we had done interfaces better"
Less common comment: "We thought hard about the interfaces so it was easy to make changes without breaking anything"
Try to stay friends!
31
Design: Build vs. Buy
OK to use modules/code from elsewhere E.g., copy or adapt open source Identify what you have used, and where it
came from
Overall project design must be your own So does selection and assembly of
components So does the bulk of the work
32
Working with Instructors
You will run your project We will help
TA: first-level "manager" More mentoring and monitoring It's your project, not the TA's
Lead instructor: second-level "manager" Again, more mentoring and monitoring