WRM Software Design Document

[Company name] [WRM] [Project lead Name] [06/05/2009] [Document Version]

______________________________

[Project Lead Signature Block]

______________________________

[Project Manager Signature Block]

TABLE CONTENTS
INTRODUCTION..............................................................................................................3 DESIGN OVERVIEW.......................................................................................................4 USER CHARACTERISTICS...........................................................................................4 REQUIREMENTS AND CONSTRAINTS.....................................................................4 SYSTEM ARCHITECTURE............................................................................................6 DETAILED DESIGN......................................................................................................10 DATA ARCHITECTURE...............................................................................................14 INTERFACE REQUIREMENTS..................................................................................16 USER INTERFACE........................................................................................................16

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009 Revision Sheet Revision Number 01 Date Date Brief summary of changes Baseline draft document

ii

Revision Sheet

Version 1.0

[WRM] Software Design Document Date

Introduction
This document specifies the class diagrams set for Web Recipes Management site. Web based Recipes Management (WRM) is a Social Networking Site, The purpose of the site is to implement application for easy recipe viewing, saving and sharing.

1.1Purpose
This document specifies the classes diagram for this project; it provides details for the classes of the program. The details, for each class includes: description of the class, relationships with other classes, functions, methods, attributes and properties of the class. This SDD is intended for the following audience: The system development team that will implement the classes defined in this document.

1.2Scope
The design of the classes will be based on the Three-Layer Architectures: data layer, logic layer and GUI layer, The implementation will be based on Java Shindig Open Social Reference implementation. This document defines all the system classes for the data and logic layer, and the base classes of the GUI layer. The GUI layer contains the web pages and forms. some of the pages of the system will be built at run time by the Gadget Server (explained in sect. 5), The other Gui layer classes will be defined later. The classes definition might change throughout the development process, this document will evolve with the development lifecycle.

1.3Definitions, Acronyms, and Abbreviations

SDD DFD CD SCM WRM SAR SNS Software Design Document Data Flow Diagram Class Diagram Software Configuration Management Web Recipe Management Smart Agent Request Social Networking Site

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009

1.4References
Other documents or material of which the reader should be aware: SRS: Software Requirements Specification-WRM.

Design Overview
1.5Background Information
The design of the classes will be based on the Three-Layer Architectures. Classes in the data layer consist of Database Servers, in this classes the information is stored and retrieved. This layer keeps data neutral and independent from application servers or business logic. Giving data its own layer also improves scalability and performance. Classes in the logic layer consists all the business logic and processes of the program. Classes in the GUI layer consists all the web pages/forms that will be view by the users. The implementation of the site, will be based on Java Shindig Open Social Reference implementation which is a set of common APIs for building social network. As mentioned, the class's definition might change throughout the development process.

User Characteristics
The base users which will use the system are not experienced computer users, therefore the system will be very easy and intuitive to use. The user is expected to understand and use computers basic, input/output devices such as a keyboard and mouse and web surfing. There are three types of users: Guest User- An anonymous user in site. Registered User- User that registered by fill in a registration form. Administrator- The website administrator with expanded privileges.

In the classes diagram we define a speared class for each type of user. For the guest and registered user, in the GUI layer, the GUI classes will be defined with extra care for user friendly design.

Requirements and Constraints

4 Version 1.0

[WRM] Software Design Document Date

1.6Performance Requirements
By using web server that serves all client requests through poplar web browsers we ensure that the application meets the performance requirements as describe in the SRS document. The web server forward request to Open Social Network server. The OSN servers committee to performance that meets our request and is good infrastructure for performance assurance.

1.7Security Requirements
Using the OSN security system named OAuth will ensure user authentication rule based.

1.8Design Constraints
The biggest constraint is time. By scheduling project delivering to first quarter of June not all components will be delivered.

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009

System Architecture
Introduction The purpose of this document is to explicate the detailed technical architecture of the WRM Website, which is a Social Networking Site (SNS) based on Java Shindig Open Social Reference implementation. Software Stack This section enlists all the software that has been used for the application development. Java 1.6 JavaDB (Derby) Java Shindig Server(OpenSocial-0.9) Glassfish V3 Prelude Server (J2EE Java Application Server) JSF 1.2 with Facelets 1.1 Open Social Overview Open Social is a set of common APIs for building social. Open Social allows developers to write applications to a common standard API that will run on multiple websites. It is being developed by Google in conjunction with partners from the Web/Social Application development community The core Open Social services include People and Friends Data API - Access friends information programmatically. Activities Data API - See what youre friends are up to Share what you are doing. Persistence Data API - Share data with your friends, the world. Additional Gadgets services include Gadgets Core - Utilities handling gadget preferences, IO, JSON. Gadgets Feature-Specific - Utilities for working with flash, window management, tabs, rpc, MiniMessage. http://www.opensocial.org/

Version 1.0

[WRM] Software Design Document Date

Architectural Components

Figure WRM Application Architectural

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009

Shindig Application Overview What is Shindig? Open Source software that allows you to serve Open Social applications. Shindig is an Open Social container and helps you to start hosting Open Social apps quickly by providing the code to render gadgets, proxy requests, and handle REST and RPC requests. Shindig's primary goal is to provide infrastructure for those wishing to host Open Social apps on their websites. http://incubator.apache.org/shindig/ Shindig is the reference implementation of Open Social API specifications, a standard set of Social Network APIs which includes: Profiles Relationships Activities Shared applications Authentication Authorization Shindig server side main components This is basically web container that hosts Java Social Networking Site (SNS) which supports various different features. To make this site open social compatible, i.e., it can host the Open Social gadgets; it is integrated with Shindig Java Server, which is an open source implementation of the Open Social specification and gadgets specification. SNS site is also referred as container, as it can host the Open Social gadgets and conforms to the open social specifications. Gadget Server - The sole responsibility of this component is to handle the Gadget Rendering request and returns the rendered component over the HTTP protocol. This component works vis--vis Gadget Server which renders the gadget XML into JavaScript and HTML for the container to expose via the container JavaScript. Open Social Container - JavaScript environment for people, activities, persistence. Social Data Servlet - Handles requests for data and sends to data handlers. Open Social REST APIs - The Restful capabilities of the Shindig container are exposed through this handler. It serves to fulfill the Open Social data request via RESTful calls. When a gadget is rendered within the SNS, it simultaneously makes the OpenSocial data request, which is handled through this component of Shindig Container..

Version 1.0

[WRM] Software Design Document Date

Open Social Container WRM Implementation Shindig Service Layer comprises of the services which conforms to OpenSocial specs. It comprises of People Service, Activity Service, and Application Service. Elaboration to each of the services is given below: People Service People Service provides the list of people and friends bound to this WRM SNS. This service forms the epicenter of complete OpenSocial spec. Activity Service The Activity Service defines the service provider interface to retrieve the activities (Recipe activity) from the underlying SNS database. Application Data Service The Application Service defines the service provider interface that is used to retrieve information bound to a person. Also, there are methods to update a delete data.

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009

Detailed Design

Class Diagram

Figure Class Diagram

10

Version 1.0

[WRM] Software Design Document Date

Class Description
Name Purpose Superclass Interface Attributes WRMDataService.java

Handle the user personal data. Use the WRMDataLayer to retrieve the data from the DB, or update the data in the DB.

org.apache.shindig.social.opensocial.DataService WRMDataLayer getPersonData() return ResponseItem containing user data to be used by Shindig updatePersonData() updates user data and returns a ResponseItem to be used by Shindig
WRMPeopleService.java

Operations

Name

Purpose Superclass Interface Attributes

Handle the user contacts information. Use the WRMDataLayer to retrieve the contacts information from the DB, or update the contacts information in the DB.

org.apache.shindig.social.opensocial.PeopleService WRMDataLayer getPeople() return ResponseItem containing List of <Person>s according to IDs to be used by Shindig getContactsOfUser() return ResponseItem containing List of <Person>s friends to be used by Shindig getPerson() - return ResponseItem a <Person> according to ID to be used by Shindig

Operations

11

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009

Name Purpose Superclass Interface Attributes WRMRecipeService.java

Handle a recipe data. Use the WRMDataLayer to retrieve the recipe data from the DB, or update the recipe data in the DB.

org.apache.shindig.social.opensocial.ActivitiesService WRMDataLayer getRecipes() return ResponseItem containing List of <Recipe>s according to IDs to be used by Shindig createRecipe() create a new Recipe and return ResponseItem containing it to be used by Shindig getRecipe() - return ResponseItem a < Recipe> according to ID to be used by Shindig
Group.java

Operations

Name Purpose Superclass Interface

Handle group definition and data

Attributes

name name of the group description description of the group persons list of <Person>s in the group addPerson() add a <Person> to the group removePerson() remove a <Person> from the group

Operations

12

Version 1.0

[WRM] Software Design Document Date

Name Purpose Superclass Interface Person.java

Entity which holds a person information

Attributes

id id of the person name name of the person published date the account was created updated date the account was updated birthday birthday of the person gender gender of the person note note inserted by the person recipes list of <Recipe>s of the person address address of the person addRecipe() create a new Recipe if needed and insert the Recipe to the Person list of Recipes removeRecipe() remove a Recipe from the Person list of Recipes
Address.java

Operations

Name Purpose Superclass Interface

Entity which holds a persons address details

Attributes

streetAddress postalCode country city

13

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009

Name Purpose Superclass Interface Recipe.java

Entity which holds a recipes details

Attributes

name name of the Recipe description description of the Recipe summary summary of the Recipe avgGrade average grade of the Recipe numOfGraders number of <Person>s who graded the Recipe visibility determines the level of visibility of the Recipe (private/group/public) gradeRecipe() calculate the grade of the Recipe after getting a new grade comment() add a comment on the Recipe setVisibility() set the visibility of the Recipe

Operations

Data Architecture
1.9Data Analysis
[A brief description of the procedures used in support of data analysis activities should be described in this section. Any analysis of the data that resulted in a change to the system design, or that impacted system design, should be noted.] At this stage at least 3 Stored Procedure will be used to analys data. Data Analysis provided by stored procedure : Average recipe grade. User recipes. User login. User friends. Other Data Analysis will be considered on demand.

1.10

Output Specifications

Sending mail feature will be support if Mail Server is presente.in this stage, sending mail is a feature.

1.11
14

Logical Database Model

Version 1.0

[WRM] Software Design Document Date

Figure Data Model 1

15

Version 1.0

[WRM] Software Requirements Management Plan06/05/2009

Interface Requirements
Interface requirements are referenced in the SRS document chapters 2.2 and 4.3.

User Interface
WRM website GUI is based on OpenSocial Templates.

16

Version 1.0