A Project Report on Online Photo Management System Submitted ...

knifedamagingInternet and Web Development

Feb 2, 2013 (4 years and 8 months ago)

143 views



A Project Report on

Online Photo Management System






Submitted by

Carlos Kirckonell

Mallikarjuna Pinjala

Mustafa Mohammed

Srinivas Gudelli
















Professor: Dr. Bill Hankley

Fall 2008

CONTENTS

1) Software Requirement Specification


a) Intr
oduction


b) Purpose of the document


c) Overview of the document


2) Literature Survey


a) Unified Modeling Language


b) Rational Rose


c) Ruby on Rails


3) DESIGN VIEW


a) Use


Case Diagram


b) Class Diagram


c) Sequence Diagram


4) SCREEN SHOTS


5) REFERENCES






a)
Introduction

This system namely photo
-
system manages digital images as a web service,
specifically focused for use by commercial photographers and publishers.


This web
service contains images for professional use. This stores images

and additional
information like EXIF and IPTC into the database.




b)

Purpose of the project

This project could be used for professional purpose wherein the photographer can
use web service to post the images liked by the customer on the web in their pri
vate
gallery.


c)
Overview of the project



The photographer uploads images with meta information. The photographer
makes images accessible to a specific customer. Customers can select by specific contact
or can search using search option on keywords
, name of the photographer or title. The
photographer can define an order for a customer or a customer can request an order,
which is approved or refused by the photographer. After order has been approved, and the
images uploaded, the customer can view the

order and download the photos.
Photographers can see their approved and delivered orders.

A system administrator would have additional control to monitor status of the system

and to enter photographers and customers.











LITERATURE SURVEY


a)
Unifie
d Modeling Language:

The Unified Modeling Language (UML) is a visual modeling language used to specify,
visualize, construct and document a software intensive system. The embedded real time
software systems encountered in applications such as telecommunica
tions, school
systems, aerospace, and defense typically tends to be large and extremely complex. It is
crucial in such systems that the software is designed with a sound architecture. A good
architecture not only simplifies construction of the initial syst
em, but also, readily
accommodates changed forces by a steady stream of new requirements.


The UML represents a collection of best engineering practices that have proven
successful in the modeling of large and complex systems. The UML is a very important
p
art of developing object oriented software and the software development process. The
UML uses mostly graphical notations to express the design of software projects. Using
the UML helps project teams communicate, explore potential designs, and validate the
architectural design of the software.


The primary goals in the design of the UML are:

Provides users with a ready
-
to
-
use, expressive visual modeling language so they can
develop and exchange meaningful models.

Provide extensibility and specialization mech
anisms to extend the core concepts.

Be independent of particular programming languages and development processes.

Provide a formal basis for understanding the modeling language.

Encourage the growth of the OO tools market.

Support higher
-
level development
concepts such as collaborations, frameworks,
patterns and components.






The UML itself distinguishes two types of models:


Structural models: Represent the pieces of a system and their relationships.

Dynamic models: Represent the behavior of the element
s of the system and their
interactions.


Models are made up of model elements. Model elements are named uniquely in the
context of a given namespace and have visibility, which defines how they can be used by
other model elements. Visibility determines the
way individual elements can connect
with each other. Therefore, it is a critical part of managing the complexity of models via
information hiding. Decisions about visibility can be powerful factors influencing
decisions about the logical organization of mo
dels. It is one of the ways in which the
UML is distinctly different from previous generations of modeling languages and tools
-

by leveraging and extending the notion of visibility from Object
-
Oriented languages
themselves.


In UML, model elements may be v
isible in one of the three ways:

Public: Any outside model element can see the model element.

Protected: Any descendent can see the model element.

Private: Only the model element itself, its constituent parts, and the model elements
nested within it can se
e it.



Diagrams
:


Semantically, diagrams express views of a model. An individual model element can be
presented in one or many of the diagrams for a model; in other words, a model element
can be presented in at least one diagram in one way. Diagrams don’t

have any special
shape assigned to them; they can be free
-
floating, bounded by a box, or contained within
a package.


The UML specification highlights three kinds of visual relationships in diagrams:

Connection: Lines connect icons and symbols, forming co
nnecting paths. Paths are
always attached to symbols at both ends.

Containment: Boxes, Circles, and other fully enclosed shapes contain symbols,
icons and lines.

Visual Attachment: Elements that are close together may have a relationship
suggested by their

proximity. For example, a name above a line or next to a box
may be interpreted as applying to the line or box.

Packages
:




A package is a grouping of UML elements, which can include diagrams and may
include subordinate packages and other kinds of m
odel elements. According to the UML
specification, packages “can be used for organizing elements for any purpose; the criteria
to use for grouping elements come together into one package are not defined within
UML”. Packages are probably the most important

aspect of the UML modeling that is
similar to the role, which the classes play in programming.


Symbols
:





UML symbols can have content or just be iconic. Actually, the UML
distinguishes between what it calls, awkwardly, two
-
dimensional symbols and i
cons.


UML diagrams are where it all comes together. In the UML there is no formal way of
bounding or counting a diagram, so there are no relationships between diagrams. Instead,
diagrams are the graphical representation vehicles for aspects of a model. Th
e UML
specifically include nine different diagrams in documentation. However, these diagram
types are process dependent and suggestive. The diagrams included for the current
project include the Use
-
Case diagram, the Class diagram, and the Sequence diagram.




b)
Rational Rose

:

Rational Rose is the award winning Unified Modeling Language
-

based model
driven development tool that is part of Rational Software’s comprehensive and fully
integrated software development solution. By using UML, Rational Rose and o
ne’s
favorite configuration control solution enables all team members to use one tool and one
language to communicate effectively. Rational Rose will enable one to develop
individually, communicate collaboratively and deliver better software. Rational Ros
e is a
complete solution for: Enable analysts to visualize and model business processes and
system requirements, publish designs and model to one’s website in HTML, sharing
business models within the entire organization. Through a tight integration with
R
equisitePro, Rational’s Requirements Management solution, one can consistently and
seamlessly manage all use artifacts, including specification documents, attributes,
traceability, and diagrams.


Rational Rose allows one to move easily from analysis to de
sign to
implementation, supporting all team members throughout the project’s lifecycle. This
controlled iterative style of development lets projects begin with a set of known
requirements, and then evolve as project parameters change or new requirements ar
e
added. Rational Rose supports this dynamic change management process with forward
engineering, and model updating features, allowing one to alter one’s implementation,
assess one’s changes, and automatically incorporate them into one’s design. Rational
R
ose’s support for support for round
-
trip engineering ensures that the iterative
development cycle is controlled and predictable, avoiding the costly and time consuming
changes that afflict most software projects.








Ruby On Rails

Introduction:



Ruby o
n Rails is a framework that makes it easier to develop, deploy, and

maintain web applications. What makes Rails different? We can answer that question a
number of ways.

One way is to look at architecture. Over time, most developers have moved

to a Model
-
Vi
ew
-
Controller (MVC) architecture for serious web applications.

They find that MVC helps them structure their applications more cleanly. When you
develop in Rails, there’s a place for each piece of code, and all the pieces of your
application interact in a
standard way. It’s as if you start out with the skeleton of an
application already prepared.

Another way of answering the question is to look at the programming language.

Rails applications are written in Ruby, a modern, object
-
oriented scripting language.

Ruby is concise without being unintelligibly terse

you can express ideas naturally and
cleanly in Ruby code. This leads to programs that are easy to write and (just as
importantly) are easy to read

months later.

Ruby also lends itself to a style of progra
mming that’s familiar to Lisp coders, but
will look fairly exotic to others. The language makes it easy to create methods that act
almost like extensions to the syntax. Some folks call this metaprogramming, but we just
call it useful. It makes our programs

shorter and more readable. It also allows us to
perform tasks that would normally be done in external configuration files inside the code
base instead. This makes it far easier to see what’s going on.

A rail is a web application framework that includes ev
erything needed to create database
-
backed web applications according to Model
-
View Control pattern.

In Rails, the model is handled by what‘s called an object
-
relational mapping layer
entitled Active Record. This layer allows you to present the data from d
atabase rows as
objects and embellish these data objects with business logic methods.



Philosophy

The Rails philosophy includes several guiding principles:

DRY
-

"Don't Repeat Yourself"
-

suggests that writing the same code over and over
again is a bad t
hing.

Convention Over Configuration
-

means that Rails makes assumptions about what
you want to do and how you're going to do it, rather than letting you tweak every
little thing through endless configuration files.

REST is the best pattern for web appli
cations
-

organizing your application around
resources and standard HTTP verbs is the fastest way to go.

The MVC Architecture

Rails is organized around the Model, View, Controller architecture, usually just called
MVC. MVC benefits include:

Isolation of b
usiness logic from the user interface

Ease of keeping code DRY

Making it clear where different types of code belong for easier maintenance

Models

A model represents the information (data) of the application and the rules to
manipulate that data. In the
case of Rails, models are primarily used for managing the
rules of interaction with a corresponding database table. In most cases, one table in your
database will correspond to one model in your application. The bulk of your application's
business logic wi
ll be concentrated in the models.

Views

Views represent the user interface of your application. In Rails, views are often
HTML files with embedded Ruby code that performs tasks related solely to the
presentation of the data. Views handle the job of providi
ng data to the web browser or
other tool that is used to make requests from your application.

Controllers

Controllers provide the "glue" between models and views. In Rails, controllers are
responsible for processing the incoming requests from the web brows
er, interrogating the
models for data, and passing that data on to the views for presentation.


Figure
1
: The Model
-
view
-
Control Architecture

The Components of Rails

Rails provide a full stack of components for creating web applications, including:

Actio
n Controller

Action View

Active Record

Action Mailer

Active Resource

Railties

Active Support

Action Controller

Action Controller is the component that manages the controllers in a Rails
application. The Action Controller framework processes incoming

requests to a Rails
application, extracts parameters, and dispatches them to the intended action. Services
provided by Action Controller include session management, template rendering, and
redirect management.

Action View

Action View manages the views of
your Rails application. It can create both
HTML and XML output by default. Action View manages rendering templates, including
nested and partial templates, and includes built
-
in AJAX support.

Active Record

Active Record is the base for the models in a Rail
s application. It provides
database independence, basic CRUD functionality, advanced finding capabilities, and the
ability to relate models to one another, among other services.

Action Mailer

Action Mailer is a framework for building e
-
mail services. You c
an use Action
Mailer to send emails based on flexible templates, or to receive and process incoming
email.

Active Resource

Active Resource provides a framework for managing the connection between
business objects an Restful web services. It implements a wa
y to map web
-
based
resources to local objects with CRUD semantics.



Railties

Railties is the core Rails code that builds new Rails applications and glues the
various frameworks together in any Rails application.

Active Support

Active Support is an extensi
ve collection of utility classes and standard Ruby
library extensions that are used in the Rails, both by the core code and by your
applications.











DESIGN VIEW


a)
Use Case Diagram


Create Public Gallery
Create Private Gallery
Upload
Photographer
View Public Gallery
Make Order
Get Private Gallery
Download
Customer










b)
Class Diagram’s


Active Records






Action Control
ler




























c)
Sequence Diagram’s


Make an Order

Customer
GUI
Gallery
Controller
Gallery
Make an Order
submit
create
self.create
we are
assuming that
the customer
is viewing the
create form




















Fill Gallery



Phoographer
GUI
File System
Gallery
Controller
Gallery
Photo
Controller
Photo
EXXIFF
select
galleryid
edit
self.find
id
fopen
upload
upload
complete
update
save
self.create
before_create
get_metadata
since gallery is
sent, their is no
need to call
gallery.addphoto
Fill gallery
















c)
View Gallery


Customer
GUI
Gallery
Controller
Gallery
Photo
Controller
Photo
view
show
self.find
self.find
photoid
download
download
self.find
[photoid]
get_blob
[key]
View Gallery
















SCREENSHOTS

a) Home page with list of Photographers






















































REFERENCES

Ruby on Rails PDF, Nov 12 2008

<
http://people.cis.ksu.edu/~carlosk/temp_4321/agilewebruby.pdf
>


Official Ruby on Rails Web Site, Nov 12 2008

<
http://www.rubyonrails.org/
>


Free Screen Casts, Nov 12 2008

<
http://railscasts.com/
>