You are on page 1of 10

Software Architecture Document


Group Name GAMMA-J

Group Project Subtitle GAMMA-J Web Store

Team Members:
Ashwini Chavate
Minesh Dhyani
Glenn Hollander
Avishek Shrestha
Jose Tellez
Marc Weber


1. Introduction

This document provides a high-level overview of the technical architecture of the GAMMA-J USB
Web Store appliance. It highlights the technology and the goals of the architecture in its
entirety. It will show the different perspective or views of the software, define the size and
performance, and list the expectations in quality attributes.

1.1 Purpose

The purpose of this document is to set up the framework for the development of the design
documentation. Additional documents will guide the developer in creating the underling

1.2 Scope

The scope of this document is centered on the design architecture of web store software. It will
not break down the design of the hardware, USB key, operating system, web server or SQL

1.3 References

The following documents were used to create this document:

• System Overview
Consists of a marketing statement, technology statement, opportunity statement, and
the strategic target.
• Functional Needs Statement
A brief outline and description of all of the functions planed for version 1 of the GAMMA-J
Web Store
• Stakeholder Goals list
A list of the stakeholders specific goals, needs, and concerns
• Software Requirements Specification (SRS)
An outline of all of the functions, capabilities and requirements for Version 1 of GAMMA-
J’s Web Store.

2. Architectural Representation

The architecture for this appliance is represented in the following views:

• Use-Case View
This is a model representing the use-cases explained in the SRS
• Logical View
This is a model depicting significant parts of the design model, such the web server,
services and plug-in interfaces. It also represents a brief description of their
responsibilities, as well as a few very important relationships, operations, and attributes.
• Process View
This model depicts the communications between processes such as message passing
and interrupts. It describes the system’s decomposition and threading as well.
• Deployment View
This depicts the physical hardware and how it is interconnected onto the physical nodes.
• Implementation View


This model represents the overall structure of the implementation, the decomposition of
the software into layers and subsystems implementation.
• Data View
A brief description on data storage and constraints

3. Architectural Goals and Constraints

The overall goal of this product is to create a foundation for further products that can be ported
to other internet appliances. The structure shall be made expandable from the onset via a plug-
in design. The version for the USB key is targeted towards people new to e-commerce.

Security: The design of this software product does not contain any security features other than
SSL to keep user communications private. The user will be urged to use a proven security
product, such as the Yoggie Pico Security Key on the host computer in order to protect it from
malicious attacks.

Connectivity: This product does not provide any internet connectivity. The user will need to
have a host computer with an internet connection, along with an internet service provider.

Uniform Resource Locator (URL): This product does not provide a URL therefore, the user will
need to register their URL through a privet vender.

4. Use-Case View

Below is a visual depiction of the use-cases described in the GAMMA-J Web key Software
Requirements Specification:

5. Logical View

5.1 Overview


The user with the web browser interacts with the web server over an HTTPS connection. The web
browser relays the actions from the web browser to the various system services. The system
services interact with the database and plug-in API. The plug-in API then sends the requests to
the individual plug-ins. After the system completes the requests, the web server displays the
information to the user with the web browser.


6. Process View

Below is a visual representation of the processes described in the GAMMA-J Web key Software
Requirements Specification:


7. Deployment View

The deployment of the web store will consist of one or more GAMMA-J Web USB keys connected
to a host computer with a USB. A sales and administrator computer can be used to edit the
store’s inventory, edit user account information or install updates. The sales and administrator roll
can also be accomplished with the host computer. If needed a mirror site can be used as
remote storage to improve reliability. Finally, there will be a customer base. All of these systems
except for the USB Web Store will be connected to the host computer via the internet. The USB
Web store will be connected directly to a USB port on the host computer.

8. Implementation View

8.1 Overview
This model represents the overall structure of the implementation, the decomposition of the
software into layers and subsystems implementation.

8.2.1 Presentation Layer

The presentation layer contains the components for end-user interaction. It consists of:
• Microsoft Internet Explorer version 6 and 7
• Netscape Communicator Version 4 and 5

8.2.2 Control Layer


The Control layer is the components used to interact with the resource layer and the domain
layer. It consists of:
• Slackware Linux 2.6
• Apache Web Server

8.2.3 Resource Layer

The Resource layer contains components that enables communication between the Domain
Layer and the Control Layer. It consists of:
• MySQL 5.0 Server
• Internet Service Provider
• Mirror Site

8.2.4 Domain layer

The Domain layer contains the object oriented model and performs all business related tasks. It
consists of:
• Web Store System

8.2.5 Common Elements Layer

There are no Common Elements in the current version of this design.

9. Data View (optional)

The systems data will be stored via the USB hardware which it operates on. All transactions and
logs will be stored via the mySql database that comes prepackaged with the web store.
Furthermore, the way that data is being read and written follows the same traditional methods
of USB read/write mechanisms.

10. Size and Performance

The architecture of our system is impacted by the current market on hardware, specifically USB,
storage devices. As the market changes and storage devices are made both bigger and
cheaper, our architecture will grow with this growing market. Although the technology of hosting
a web store through an USB drive is in its infancy stages, it is up to par with most big web servers
out on the market right now. As this technology improves our application will be able to offer a
greater performance outcome. Performance is only degraded by the same environment
influences that degrade other web servers. This factor is related to internet connectivity, which
plays a huge role on how fast the web server is updated, and how fast consumers can view and
purchase products from the site.

11. Quality

Early in the development process our architecture has been derived by early performance
benchmarks which we have lived by these initial readings. This method has proven to ensure
that our system performs at its optimum level and when performance is degraded by another
quality attribute we make distinctions between how much performance we are willing to give
up based on the return of these other quality attributes. In general, the architecture of our
system has been created with the intention of being very light in size because of its hardware


The architecture approach we took is to encrypt all of the data so in the event that our security
is compromised our customer's information is not. We have also added several security layers
that will detect intrusions and breaches. Furthermore, all of the information pertaining to security
is logged and tracked.

The architecture has been created so that no minimal down time is ever encountered. However,
in the event of any downtime that is due to upgrading conflicts, the application can easily
restore itself to previous versions in a matter of minutes. All updates are advice to be done
during non-business hours, in order to avoid any customers being compromised by such down

The architecture has been designed with two primary attributes: usability and functionality. Our
organization has enabled the execution of both of these quality attributes through constant
interaction with users and through the pre-release of beta versions. Every use case has been
thoroughly reviewed, validated, and verified by the very users who will be using the system. We
have given some of the products at huge discounts to these specific users in addition to
monetary compensations in appreciation for their input.

The architecture does leave room for the ability to have mirrored web servers. This enables our
system to be able to run through two or more mediums. In addition, this also aids in cluster
farming by making it so that if one site goes down the other picks up and therefore increases our
availability up time.

The architecture itself has been done so that different components and features can be
interchangeable in the system without resulting in any conflicts. This approach has helped the
architecture to introduce new versions of itself and features with minimal to no code conflicts.

The USB interface in the architecture has helped our system to become highly portable. Due to
the integration of this specific feature, the ability to plug and play into any other system has
become easier. Thus, migrating the web store from one system to another is just as easy plugging
it in.

The architecture has been specifically drafted so that the essential ingredients within the code
can be easily reusable without having to reinvent the wheel. By creating object oriented classes
and interfaces, it has aided us with both the application maintenance and the reuse of key
components for future versions.

Due to the systems sheer size, we created a second system that is responsible for running bench
marks and test cases that mimic the user/customer experience. Every function is tested and
every result is logged. New features and updates are run through the system and analyzed.
Before it is considered complete, every function is carefully analyzed to ensure that it will comply
with our testing methods in order to acquire the correct quantitative measures.

Cost and Schedule


The architecture for this system was created in cooperation with Yoggie's USB storage device
system. Our schedule was very rigorous, since we needed to release something before any of
the other competitors. We also wanted to complete the software side in correlation with
Yoggie's finalization of the USB device. The expected project lifetime was very short, and it was
because of this deadline that we guided our business strategy to release a trimmed down
version under the expected schedule. This change of direction enabled us to get something
very minimal out the door but with the ability for customers to purchase these additional
components at a later time. By changing our business strategy it enabled us to both beat our
competitors and release with our business partner Yoggie as well.

The release of this system was orchestrated in order to take advantage of a unique market.
There is currently no system out there that will accomplish all of the quality attributes, specifically
the portability attribute, therefore beating our competitors was highly critical. Other hardware
vendors will be releasing similar systems in the next year or two, therefore for both Yoggie and us
to get out on the market as quickly as possible was crucial and important.