260 likes | 377 Views
Distributed Software Development 2011/12. Search4Yummy Requirements Definition and System Architecture. Muhammad Sulyman Petar Paar Yehui Wang Ronald Wolvers. Jan Čustović Andrej Garić Ivan Bandalo Lovro Maričić. Outline. Functional Requirements Usecase Models
E N D
Distributed Software Development 2011/12
Search4Yummy Requirements Definition and System Architecture • Muhammad Sulyman • Petar Paar • Yehui Wang • Ronald Wolvers • Jan Čustović • Andrej Garić • Ivan Bandalo • Lovro Maričić
Outline • Functional Requirements • Usecase Models • Nonfunctional Requirements • External Interfaces • Components • System Architecture • Database Design
Functional Requirements Mobile application Web application Customer Staff member Restaurant System administration Guest User Administrator
Customer Requirements • Browse restaurants • Search restaurants • Popularity, location, type,seat availability, food offer, “I feel lucky” • Browse dishes • Search dishes • Price, type, restaurant
Customer Requirements • Feedback • Comments, photos, likes, recommendations • News • Certain restaurant, type of restaurant • Check-in
Restaurant Requirements • Menu update • Seat availability update • Restaurant info update • News update
System Administration Requirements • User management • Restaurant management • Restaurant staff members management
Nonfunctional Requirements 2014-11-08 16 Usability Accessibility Performance Privacy and safety Portability
Requirement Group & definitions ADM RS USM GUM USW GUW NFR Must Should Could Would Requirementdefinition
System Architecture • 3-tier application • Presentation layer • Bussiness logic • Database layer • Client/Server communications model • Each tier can be developed concurrently • Tiers communicate thru interfaces • Easy to change implementation of one tier without changing other tiers
Presentation/Bussiness layer • Struts2 MVC • Spring, Spring security • View rendering: Tiles, Freemarker, taglib, JSON, XML
Database layer • JPA/Hibernate ORM framework • Ehcache • Spring data
Design patterns • One class must do one thing (decoupled as much as possible) • Tests for important parts • Use singletons when possible • Only object itself can change its state (use getters and setters) • Respect naming convention