traderz unlimited rational sad (1)

7/31/2019 Traderz Unlimited Rational SAD (1)

1/21

Sample Software ArchitectureDocument

Swapping Skillz n Thingz 1.0

Traderz UnlimitedTeam 2

CONTENT OWNERS:Kashifuddin Qazi

Paulius Mikalainis

Rohit Warang

Salman Virk


2/21

Traders Unlimited: Swapping Skills n' Things 1.0

Sample Software Architecture Document (version 1.0) Last Updated on 6/13/2012

SAD Revision History

Date Version Description Author

2009-04-16 0.1 Significant Use-Cases : the key

requirements

TU

Architecture Team

2009-04-18 0.2 Candidate architecture : the high level

architecture of the system

TU

Architecture Team

2009-04-19 0.3 Initial Deployment Model TU

Architecture Team

2009-04-21 0.4 Key abstractions : the key data elements

used in the system

TU

Architecture Team

2009-04-22 1.0 Delivered TU

Architecture Team

Wednesday, June 13, 2012 Traderz Unlimited, 2012 Page 2 of 21


3/21



Table of Contents

1. INTRODUCTION ............................................................................................................................................................4

1.1 PURPOSE..................................................................................................................................................................4

1.2 SCOPE...................................................................................................................................................................... 4

1.3 DEFINITIONS, ACRONYMSAND ABBREVIATIONS.............................................................................................................5

1.4 REFERENCES.............................................................................................................................................................5

1.5 OVERVIEW................................................................................................................................................................ 6

2. ARCHITECTURAL REPRESENTATION ............................................................................................................... .6

3. ARCHITECTURAL GOALS AND CONSTRAINTS (NON-FUNCTIONAL REQUIREMENTS) ................ ....7

3.1 TECHNICAL PLATFORM...............................................................................................................................................7

3.2 TRANSACTION...........................................................................................................................................................7

3.3 SECURITY................................................................................................................................................................. 8

3.4 PERSISTENCE ............................................................................................................................................................ 8

3.5 RELIABILITY/AVAILABILITY (FAILOVER) ........................................................................................................................8

3.6 PERFORMANCE..........................................................................................................................................................8

4. SSNT USE-CASE VIEW ................................................................................................................................................9

4.1 SSNT ACTORS....................................................................................................................................................... 10

4.2 USE-CASE REALIZATIONS......................................................................................................................................... 11

5. LOGICAL VIEW ..........................................................................................................................................................12

5.1 OVERVIEW.............................................................................................................................................................. 12

5.2 SSNT RECEIVER-INITIATORSWAPPING SEQUENCE DIAGRAMS......................................................................................14

SSNT INITIATOR-RECEIVER (ACCEPTS) SWAPPING SEQUENCE DIAGRAMBELOWDISPLAYSHOWTOWEBUSERS INITIATORAND

RECEIVERINTERACTBETWEENEACHOTHERTHROUGHWEBSERVERDURINGASSETSWAPPINGPROCESSWHEN RECEIVERACCEPTSINITIATORSREQUEST/OFFER: ...........................................................................................................................................14

5.3 SSNT PROCESS DELIVERY DIAGRAM........................................................................................................................ 15

.................................................................................................................................................................................. 15

6. SSNT PROCESS VIEW ...............................................................................................................................................17

7. SSNT DEPLOYMENT VIEW ................................................................................................................................... .18

8. DATA VIEW ................................................................................................................................................................. .18

8.1 SSNT ENTITY RELATIONAL DIAGRAM (ERD) ...........................................................................................................19

8.2 SSNT RELATIONAL SCHEMA.................................................................................................................................... 19

9. SIZE AND PERFORMANCE .....................................................................................................................................20

10. QUALITY ....................................................................................................................................................................21



4/21



1. Introduction

This document provides a high level overview and explains the whole process of Swapping Skillz n Thingz 1.0. It

explains how an online user will be able to swap assets on website and it includes the underlying architecturalprocess.

The document provides a high-level description of the goals of the architecture, the use cases support by the systemand architectural styles and components that have been selected to best achieve the use cases. This framework thenallows for the development of the design criteria and documents that define the technical and domain standards indetail.

By analogy the architecture of a building has to take into account the use of the building, what are the peopleliving/working in it expecting and then has to define the size, shape, structure and so forth. The architecture has a setof guiding principles as well as known criteria and constraints that shape the proposed architecture. The designersthen have to develop detailed specifications not only for the selection of materials but the placement of wiring,plumbing, lighting and so forth. Finally the building is finished and populated in accordance with the vision outlinedprior to the first pen touching the draftsmens paper.

1.1 Purpose

The Software Architecture Document (SAD) provides a comprehensive architectural overview of Swapping Skillz

n Thingz 1.0 offered by Traderz Unlimited team 2. It presents a number of different architectural views to depict

different aspects of the system. It is intended to capture and convey the significant architectural decisions which

have been made on the system.

In order to depict the software as accurately as possible, the structure of this document is based on the 4+1 model

view of architecture [KRU41].

The 4+1 View Model allows various stakeholders to find what they need in the software architecture.

1.2 Scope

The scope of this SAD is to depict the architecture of the Swapping Skillz n Thingz 1.0 online application created

by the company Traderz Unlimited team 2.

This document describes the aspects of Swapping Skillz n Thingz 1.0 design that are considered to be

architecturally significant; that is, those elements and behaviors that are most fundamental for guiding the

construction of Swapping Skillz n Thingz 1.0 and for understanding this project as a whole. Stakeholders who



5/21



require a technical understanding of Swapping Skillz n Thingz 1.0 are encouraged to start by reading this

document, then reviewing the Swapping Skillz n Thingz 1.0 UML model, and then by reviewing the source code.

1.3 Definitions, Acronyms and Abbreviations

SSNT - Swapping Skillz n Thingz 1.0

PHP - Hypertext Processor scripting language

MySQL relational database management system (RDBMS)

HTTP Hypertext Transfer Protocol

WWW World Wide Web

Apache Web Server

TU - Traderz Unlimited

SAD - Software Architecture Document

RUP - Rational Unified Process

UML Unified Modeling Language

Asset - An asset is any skill or good that can be offered to or requested for by users.

Generic User - This is any user who is registered on the website and wants to offer or request

assets.

Initiator - This is a user who initiates a transaction by offering an asset or requesting for one.

Receiver - This is a user who receives the offer or request made by another user.

Administrator - This is a webmaster whose primary role is to maintain the website and keep itup and running. He has sound knowledge of web development and database management. He

has full authority to add or remove anything from the website which he deems necessary.

Private Profile - This is a collection of personal information of each user. Each user has

his/her own private profile, which can be accessed only by the respective user or the

administrator. The private profile contains information such as full name and address of the

user, email address, area of expertise, interests, requested/offered assets etc.

Public Profile - This is a collection of information of a particular user that is visible to other

users. The public profile includes information such as User ID, Asset Category, Asset Title,

User Ratings etc. A more comprehensive list can be obtained from the Use Cases listed in this

document.

1.4 References

[Vision-Doc]: SSNT, Vision document

[UC-Doc]: SSNT, Use Case document

[SRS-Doc]: SSNT, SRS document

[SDD-Doc]: SSNT, Software Design Document



6/21



[MedBiquitous]: Sample SAD,http://medbiq.org/std_specs/techguidelines/softwarearchitecture.pdf

[KRU41]: The 4+1 view model of software architecture, Philippe Kruchten, November 1995,

http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf

[RUPRSA]: Developing a J2EE Architecture with Rational Software Architect using the Rational

Unified Process, IBM DeveloperWorks, Jean-Louis Marchaux, Mars 2005,

http://www-128.ibm.com/developerworks/rational/library/05/0816_Louis/

1.5 Overview

In order to fully document all the aspects of the architecture, the Software Architecture Document contains the

following subsections.

Section 2: describes the use of each view

Section 3: describes the architectural constraints of the system

Section 4: describes the functional requirements with a significant impact on the architecture

Section 5: describes the most important use-case realization.

Section 6: describes designs concurrency aspects

Section 7: describes how the system will be deployed.

Section 8: describes any significant persistent element.

Section 9: describes any performance issues and constraints

Section 10: describes any aspects related to the quality of service (QoS) attributes

2. Architectural Representation

This document details the architecture using the views defined in the 4+1 model [KRU41], but using the RUP

naming convention. The views used to document the Traderz Unlimited application are:

Logical viewAudience: Designers.Area: Functional Requirements: describes the design's object model. Also describes the most importantuse-case realizations and business requirements of the system.

Related Artifacts: Design model

Process viewAudience: Integrators.

Area: Non-functional requirements: describes the design's concurrency and synchronization aspects.

Related Artifacts: (no specific artifact).

Implementation viewAudience: Programmers.

Area: Software components: describes the layers and subsystems of the application.

Related Artifacts: Implementation model, components

http://medbiq.org/std_specs/techguidelines/softwarearchitecture.pdfhttp://medbiq.org/std_specs/techguidelines/softwarearchitecture.pdfhttp://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdfhttp://www-128.ibm.com/developerworks/rational/library/05/0816_Louis/http://medbiq.org/std_specs/techguidelines/softwarearchitecture.pdfhttp://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdfhttp://www-128.ibm.com/developerworks/rational/library/05/0816_Louis/


7/21



Deployment viewAudience: Deployment managers.

Area: Topology: describes the mapping of the software onto the hardware and shows the system's

distributed aspects. Describes potential deployment structures, by including known and anticipated

deployment scenarios in the architecture we allow the implementers to make certain assumptions on

network performance, system interaction and so forth.

Related Artifacts: Deployment model.

Use Case viewAudience: all the stakeholders of the system, including the end-users.Area: describes the set of scenarios and/or use cases that represent some significant, central functionality ofthe system. Describes the actors and use cases for the system, this view presents the needs of the user and iselaborated further at the design level to describe discrete flows and constraints in more detail. This domainvocabulary is independent of any processing model or representational syntax (i.e. XML).

Related Artifacts : Use-Case Model, Use-Case documents

Data view (optional)Audience: Data specialists, Database administrators

Area: Persistence: describes the architecturally significant persistent elements in the data model

Related Artifacts: Data model.

3. Architectural Goals and Constraints (non-functional requirements)

This section describes the software requirements and objectives that have some significant impact on the

architecture

3.1 Technical Platform

Server side

SSNT will be hosted on one of NJITs AFS Apache web servers and connecting to one of theschools MySQL Database servers. The web server is listening on the web standard port 80.Web server will accept all requests from the clients and forward them to the specific SSNTserver hosting location. All communication with client has to comply with public HTTP, TCP/IPcommunication protocol standards.

Client SideClients will be able to access SSKNT only on WWW. Clients are requiring using a modern webbrowser such as Mozilla Firefox 1.5, Internet Explorer 6 or Safari 1.0. The target operatingsystems are Windows XP, Vista, Mac OS X Leopard and Linux.

3.2 Transaction

SSNT online application is transactional, leveraging the outside payment utilities such as PayPal.



8/21


9/21



4. SSNT Use-Case View

This is a list of use cases from the use-case model that represent significant, central functionality of the final system.The use-cases with a significant impact on the architecture are [UC-Doc]:

1. Create an Account

2. View Private Profile

3. Edit Personal Information

4. Post Assets

5. Search for Assets

6. View Public Profile

7. Start Automatic Search

8. Initiate Request/Offer

9. Receiver Accep

10. Receiver Denie

11. Initiator Accept12. Initiator Denies

13. Leave Feedback

14. Post Success Story

15. Log Off

16. Edit Profile

17. Delete Profile

18. Edit Success Story

19. Delete Success Story



10/21



4.1 SSNT Actors

As described in the actors correspondence diagram below, web user could be one of three types:

1. Web Administrator has enhanced privileges to edit or delete private profiles as well as success stories.

2. Web User Initiator could as well be a receiver depending if he or she is initiating or receiving an

offer/request but not both at the same instance. Initiator is a user who initiates a request or an offer.

3. Web User Receiver could as well be an initiator depending if he or she is initiating or receiving an

offer/request but not both at the same instance. Receiver is a user who receives requests from initiator for a

request or an offer.

System Apache Web Server is the third type of actor and is the system itself. It handles all the physical and

logical process of the software.



11/21



4.2 Use-Case Realizations

Use case functionality diagram below describes how design elements provide the functionalities identified in the

significant use-cases. In this diagram generic user is assumed to be the same person as initiator or receiver. Use

cases are displayed as functionalities for the system. Functionality may enclose more than one use-case. It is

assumed that signin is default functionality and it has to be implemented before any further functionality will be

enabled.



12/21



5. Logical View

5.1 Overview

SSNT is divided into layers based on the N-tier architecture [KRU41].

The layering model of the SSNT online application is based on a responsibility layering strategy that associates each

layer with a particular responsibility.

This strategy has been chosen because it isolates various system responsibilities from one another, so that it

improves both system development and maintenance.



13/21



Each layers specific responsibilities are as follow [RUPRSA]:

The presentation layer deals with the presentation logic and the pages rendering on SSNT web site. The

Presentation layer contains all the components needed to allow interactions with an end-user. It

encompasses the user interface. Snapshots of the prototype view are located in Software Design Document

[SDD-Doc].

The control layer manages the access to the domain layer. Control layer contains all the components used

to access the domain layer or directly the resource layer when this is appropriate.

The resource layer (integration layer) is responsible for the access to the enterprise information system

(databases or other sources of information). Resource layer contains the components needed to enable

communication between the business tier and the enterprise information systems: MySQL Database and

PayPal service. Refer to data view.

The domain layer is related to the business logic and manages the accesses to the resource layer. The

Domain layer contains all the components related to the business logic. It gathers all the subsystems that

meet the needs of a particular business domain. It also contains the business object model which is

specified in design document.

The Common Elementslayer gathers the common objects reused through all the layers like users and

assets. Common Element layer contains the components re-used within several layers and may be

determined in the future.



14/21



5.2 SSNT Receiver-Initiator Swapping Sequence Diagrams

SSNT Initiator-Receiver (accepts) Swapping Sequence Diagram below displays how to web users Initiator and

Receiver interact between each other through web server during asset swapping process when Receiver acceptsInitiators request/offer:

1. Initiator initiates a request/offer

2. Server Updates Receivers private profile

3. Receiver accepts request/offer and pays $1

4. Server withdraws money from receiver

5. Server updates Receivers private profile

6. Server updates Initiators private profile

7. Initiator accepts and pays $1

8. Server withdraws money from Receiver

9. Server swaps Initiators contacts with Receiver

10. Server swaps Receivers contacts with Initiator

11. Initiator leaves feedback12. Server updates Receivers private profile

13. Receiver leaves feedback

14. Server updates Initiators private profile



15/21



5.3 SSNT Process Delivery Diagram



16/21



SSNTs process delivery diagram displays not only

the sequence of functionality, interaction between

events and server responses but also explains the

logical paths.

Lets take, for example, the First Page view and call

the Sign-in function in it. This is how this example

would be explained:

1. User fills in the form on the first page clicks

on sign-in and sending data to the server

2. Server checks the validity of data and

response with invalid data by redirecting to

Reset Password page.

3. User fills in a form on this page and clicks

Reset by sending data to the server.

4. Server validates the data and returns with

valid data by redirecting user to the First

Page for Sign in again.

5. User, this time around, enters correct

information and clicks to sign in

6. Server validates the information and

redirects user to the private profile.

END



17/21



6. SSNT Process View

Theres only one process to take into account. The PHP will automatically handle threads which are instances of this

process.

The diagram below describes the process circles. There are two process circles:

User web server circle and web server-database circle. Request message from a user first will travel to a web

server. Web server first evaluated a request according to the SSNT business rules/requirements and determines if a

connection to a database needs to be established. If connection is necessary, that is completed first and only then

user is returned with response from a web server.



18/21



7. SSNT Deployment View

Global Overview

SSNTs deployment has not been considered yet. All future code and implementation details will be included in this

section. Diagram below shows that all of the PHP code will have a physical location on the Apaches web server

and all of the data entities and relationships will be physically located on the MySQL database server.

Internet

LAN/WAN

Client ClientClient Client

Firewall

Web Server Database Server

8. Data View



19/21



8.1 SSNT Entity Relational Diagram (ERD)

Entities (rectangles): User, Asset, Message, Success Story

Relationships (rumbas): Swap, Request, Offer, Gives Feedback, Post (Story), Post (message)

Initiator may swap assets with many Receivers

Receiver may swap assets with many Initiators

User may request/offer many Assets

Asset must belong to only one User

User may post many Messages

Message must belong to only one User

User may post many success stories

Success Story must belong to one user

Attributes are displayed in long ovals.

8.2 SSNT Relational Schema



20/21



User

userName firstName secondName DOB sex email password address city state zip country interests

Asset

assetId userName title category description offer status

Swap

swapId assetId initiator receiver swapTime requested accepted confirmed

Success Story

storyId userName description

Message

messageID userNameTo userNameFrom messageText postTime

Feedback

swapId userNameFrom userNameTo rating comments

9. Size and Performance

Volumes:

Estimated online orders : 100 a day, with peaks in the evening

SSNT registered individual customer : about 150

TU corporate customers : about 100

Performance:

Time to process and online payment (credit card validation + confirmation) : less that 10 seconds required



21/21



10. Quality

As far as SSNT is concerned, the following quality goals have been identified:

Scalability:

Description : Systems reaction when user demands increase

Solution : SSNT application servers support several workload management techniques

Reliability, Availability:

Description : Transparent failover mechanism, mean-time-between-failure

Solution : : SSNT application server supports load balancing through clusters

Portability:

Description : Ability to be reused in another environment

Solution : The system me be fully SSNT compliant and thus can be deploy onto any NJIT web

server

Security:

Description : Authentication and authorization mechanisms

Solution : SSNT native security mechanisms will be reused


traderz unlimited rational sad (1)

Documents