OOSE

1
Velagapudi Ramakrishna Siddhartha Engineering

College
OBJECT ORIENTED SOFTWARE

ENGINEERING LAB
Submitted By
L.VIJAYA VARMA
(148W1D5915)
Master of Technology
DEPARTMENT OF INFORMATION TECHNOLOGY

Velagapudi Ramakrishna Siddhartha Engineering College
Autonomous-NBA Accredited-Approved by A.I.C.T.E.-ISO 9001:2008
Certified- Affiliated to JNTUK, Kakinada
Chalasani Nagar, Kanuru, Vijayawada, Andhra Pradesh 520007
SEPTEMBER-2015

College
INDEX
S.NOCONTENTS
PAGENO
1. UML
1.1.Brief history
1.2.What is UML
1.3.CONCEPTUAL MODEL OF UML
BASIC BUILDING BLOCKS
RULES
COMMON MECHANISMS
2. Week 1
Find the following for a given application
2.1.Actors
2.2.Use cases with each actor
2.3.Extended or uses use cases (if applicable)
3. Week 2
Do the following for a given application
3.1.Identifying Scenarios from use case Dialog
3.2.Describing use case scenarios
3.3.Draw the complete use case diagram
4. Week 3
4.1.Draw Entity Relation Diagram
4.2.Draw Data Flow Diagram
5. Week 4
5.1.Write Flow of Events for any of 2 use cases from week 1
5.2.Draw Activity Diagram
6. Week 5
System Requirement Specification
6.1. Introduction
6.1.1. Characteristics of SRS
6.1.2. Problem Statement

College
6.1.3. Project Description

6.2. About Project
6.2.1. Existing System
6.2.2. Proposed System
6.2.3. Overview
6.2.4. Functional Requirements
6.2.5. Non-Functional Requirements
6.2.6. Implementation
6.3. Requirement specification
6.3.1. Scenarios
6.3.2. Use case Model
6.3.3. Object Model
6.3.4. Dynamic Model
6.3.5. Hardware /Software requirements
7. Week 6
7.1.Draw Sequence Diagram for a given application
8. Week 7
8.1.Draw Activity Diagram for a given application
9. Week 8
9.1.Draw state chart Diagram for a given application
10. Week 9
10.1.
Draw Component Diagram for a given application
UNIFIED MODELING LANGUAGE (UML):

1.1 A Brief History
Flow Charts
Prior to the mid 1970s, software design, if there was any, may have
been aided by the use of Flow Charts. These were diagrams of how the various
parts of a program interacted. It was primarily Procedural Oriented as opposed
to Object Oriented. A Flow Chart displayed graphically the "flow of control"
through a program.

College
Unified Modeling Language

Booch, Jacobson, and Rumbaugh were independently working toward
the same objectives. In the mid 1990s they began collaborating. The result was
the Unified Modeling Language of which the first version (then called just the
Unified Method) was released in October of 1995.
Why Use UML?
To be successful a software company must produce quality software
that meets requirements and is released on time and within budget.
This was easy to do when computers were very simple and slow devices
and programs did little more than play solitaire, convert between English and
Metric measures, and balance your checkbook.
Today when a program may be called upon to "simulate a battlefield
scenario with full and accurate engineering and physics based rendering" this
can be very difficult if not impossible without some means of organizing the
design phase.
1.2 WHAT IS UML?
The Unified Modeling Language is a standard language for writing
software blueprints.
A modeling language for specifying, visualizing, constructing and
documenting
It is used to derive system and it focuses on understanding a
subject via creating a model and it unifies the language of
communication about a system.
It can be used through the lifecycle of a system
The UML is not a visual programming language but it is a visual
modeling language
The UML is a language for formalizing the modeling of classes
or types
UML formalizes the modeling of objects or instances
WHAT IS A MODEL?

College
A model is a simplification of reality

We built models, so that we can better understand the system we are
developing
1.3 CONCEPTUAL MODEL OF UML:
To understand UML we need to form a conceptual model of the
language. This requires learning three major elements.
1. BASIC BUILDING BLOCKS
2. RULES
3. COMMON MECHANISMS
1) BASIC BUILDING BLOCKS

There are three kinds of basic building blocks. They are:
i. THINGS
ii. RELATIONSHIPS
iii. DIAGRAMS
i. THINGS IN UML:
There are four kinds of things in UML. They are:
STRUCTURAL THING
BEHAVIOURAL THINGS
ANNOTATIONAL THINGS
GROUPING THINGS
STRUCTURAL THINGS:
The structural things are nouns of UML model. There are seven kinds of
structural things.
a) CLASS
A class is a set of objects that share the same attributes, operations,
relationships and semantics.

College
Class Name
Attributes
Operations()
b) INTERFACE
An Interface is a collection of operations that specify a service of a class
or component
Student 1
c) COLLABORATION
Collaboration describes co-operative work of an element.
d) USE CASE
Use Case describes set of sequence of actions that a system performs
that yields an observable result of value to a particular actor.
UseCase
Actor
e) ACTIVE CLASS
Active class is just like a class but its elements are connected to other
class elements.
f) COMPONENT
Component represents physical packaging of logical elements like
classes, interfaces and collaborations.

College
Component
g) NODE
A Node is physical element that exists at run-time and having at least
some memory and processing capability.
Node
BEHAVIORAL THINGS
Behavioral Things are the verbs of UML representing behavior over
time and space. There are 2 kinds of Behavioral things
a) INTERACTION
Interaction is used to show communication between two objects
b) STATE MACHNE
State Machine specifies sequence of states of an object.
ANNOTATIONAL THINGS
Annotational Things are explanatory parts of UML. Only 1 type.
NOTE
Note is used to give comments to an element or collection of
elements.
Note

College
GROUPING THINGS
Grouping Things are the organizational parts of the model. Only one
type
PACKAGE
Package is a general purpose mechanism for organizing elements
or things into groups or packages.
Package
ii.
RELATIONSHIPS
There are 4 kinds of Relationships in the UML:
a) DEPENDENCY:
It is denoted by dashed line with an arrow.
Dependency is a relationship between two things in which a change to one

thing (Independent thing) may affect the other thing (Dependent thing).
MovieClip
name
screen()
start()
stop()
Dependency
Channel
b) ASSOCIATION:
It is denoted by a solid line.
____________________
Association is a structural relationship that describes a set of links, a
link being a connection among objects. Aggregation is a special kind of
association, representing a structural relationship between a whole and its
parts.
c) GENERALIZATION:

College
10
It is denoted by a solid line with a hollow arrow head pointing to the

parent
Generalization
Generalization is a relationship in which the child will share the behavior of
the parent.
Shape
origin : Integer
display()
Rectangle
length : Integer
breadth : Integer
Circle
radius : Integer
d) REALIZATION:
It is denoted by dashed lines with a hollow arrow head.
Realization is a relationship between classifiers, where one classifier specifies
a contract that another classifier guarantees to carry out
iii.
DIAGRAMS
There are 9 types of Diagrams in UML, which are classified into 2 types

College
11
1. STRUCTURAL DIAGRAMS(STATIC DIAGRAMS)

These are of 4 types:
a) CLASS DIAGRAM
A Class diagram shows a set of classes, interfaces, and collaborations
and their relationships. A class consists of class name, attributes, operations
and responsibilities.
College
name : String
location : String
Department
D_name : String
D_code : Integer
collect fees()
recruit faculty()
Staff
S_name : String
b) OBJECT DIAGRAM
An Object diagram shows a set of objects and their relationships. They
represent snapshots of instances of the things found in class diagrams.
C: College
name = "B.V.R.I.T"
location = "Narsapur"
D: Department
D_name = "CSE"
D_code : Integer = 05
collect fees()
recruit faculty()
S: Staff
S_name = "xyz"
c) COMPONENT DIAGRAM
A Component diagram shows the organizations and dependencies
among a set of components.

College
12
d) DEPLOYMENT DIAGRAM
A Deployment diagram shows the configuration of run-time processing
nodes and the components that are present in them.
Component and Deployment diagrams are called as Physical Diagrams.

2. BEHAVIORAL DIAGRAMS(DYNAMIC DIAGRAMS)
These are of 5 types
A) USECASE DIAGRAM
A Use Case diagram shows a set of use cases and actors and their
relationships. An Actor can be a human or a system. The role of actor is
written below.
INTERACTION DIAGRAMS
An Interaction diagram shows an interaction, consisting of a set of
objects and their relationships, including the messages they exchange among
them.
2 types of Interaction diagrams are:
B) SEQUENCE DIAGRAM

College
13
A Sequence diagram is an interaction diagram that emphasizes the timeordering of messages. To show interaction between objects we use 3 types of
messages.
Simple Messages:
A Simple message shows how control is passed from one object to other
without describing communication in detail i.e. without indicating whether it
is synchronous or asynchronous message.
Synchronous Messages:
If sender object waits for a reply from receiver object from destination,
such messages are called Synchronous messages. Here, only one object can
send a message at a given instance of time.
Asynchronous Messages:
If sender object continues executing while target is processing the

message then such messages are said to be Asynchronous messages. Here,
multiple messages are executed at a time.
OBJECT LIFELINE:
An Object life line is vertical dashed lines that represent the existence of
an object over a period of time.
FOCUS OF CONTROL:
It is represented by rectangle that shows the period of time during which
an object performs some actions.

College
14
C)COLLABORATION DIAGRAM
A Collaboration diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages.
3: fill form
5: check form
1: Request form
4: submit
S: Student
A: Admin
2: give form
6: eligible
D) STATE CHART DIAGRAM

A State chart diagram shows a state machine, consisting of states,
transitions, events, and activities.
Event:It refers to happening of an activity at a given time and place.

College
15
E) ACTIVITY DIAGRAM
An activity diagram is a special kind of state chart diagram that shows
the flow from activity to activity within a system, which are connected by a
triggerless transition. We can check some conditions using decision box,
which is denoted by a diamond.
Activity: It is a major task that must take place in order to fulfill an operation
contract.
Initial Activity: This shows the starting point of the flow. It is denoted by
solid circle

College
16
Final Activity: This shows the end of the flow in the activity diagram. It is
denoted by a solid circle nested in a circle.
Decision Box: A point in an Activity diagram where a flow splits into several
mutually exclusive guarded flows. It has one incoming transition and two
outgoing transitions.
FORKING AND JOINING:We use synchronization bar to specify the forking and joining of parallel flows
of control.
A synchronization bar is a thick horizontal or vertical line.
A Fork may have one incoming transition and two or more outgoing
transitions, each of which represents an independent flow of control.
A Joinmay have two or more incoming transitions and one outgoing
transition.
Student
synchronization
bar
Forking
Listen
Watch
Joining
Success
SWIMLANES:
They are used to group related activities into one column.
2. RULES
There are 2 kinds of rules
1) Well formed rules
2) Less-well formed rules
1) WELL FORMED RULES:
These are of 5 types:
a)NAMES:What you call things, relationships, and diagrams

College
17
b)SCOPE:The content that gives specific meaning to a name.

c)VISIBILITY:How these names can be seen and used by others.
d)INTEGRITY:How things properly and consistently relate to one
another.
e)EXECUTION:To run a model.
2) LESS-WELL FORMED RULES:
These are of 3 types
a)ELIDED:Certain elements are hidden to simplify the view.
b)INCOMPLETE:Certain elements may be missing.
c)INCONSISTENT:The integrity of the model is not guaranteed.
2. COMMON MECHANISMS:
There are four common mechanisms. They are:
Specifications
Common Divisions
Adornments
Extensibility Mechanism
1. SPECIFICATIONS:
The first extension mechanism that was mentioned earlier is called
specifications. This is a very easy term to grasp as we all know what a
specification means in our everyday language. In the UML it is just as simple.
By using a specification, we are basically specifying something in a bit more
detail so that the role and meaning of the term being specified is presented to
us in a more clear and concise manner. For example, we can give a class a rich
specification by defining a full set of attributes, operations, full signatures, and
behaviors. We will then have a clearer notion of what the capabilities and
limitations of that class are. Specifications can be included in the class, or
specified separately
2.Common Divisions:
This is the second extension mechanism that is provided to us by the UML.
Common divisions are used in order to distinguish between two things that
might appear to be quite similar, or closely related to one another. There exist

College
18
two main common divisions: abstraction vs. manifestation and interface vs.
implementation. In the former, we mainly talk about the distinction between a
class and an object, where the class is an abstraction and the object is a clear
manifestation of that class. Most UML building blocks have this kind of
class/object distinction, e.g. use case, use case instance etc. In the second
common division interface vs. implementation we say that an interface
declares some kind of contract, or agreement, whereas an implementation
represents one concrete realization of that contract. The implementation is
then responsible for carrying out the interface
3.Adornments:
Adornments are textual or graphical items, which can be added to the basic
notation of a UML building block in order to visualize some details from that
elements specification. For example, let us consider association, which in its
most simple notation consists of one single line. Now, this can be adorned
with some additional details, such as the role and the multiplicity of each end.
One of the most important kinds of adornments is a note. This is a graphical

symbol, which is used for adding some comments or constraints to an element
(or a collection of elements) to help clarify the models that are being created.
We may use notes in order to attach some additional information to our model,
such as an explanation, a requirement, or just simply an o observation

College
19
It is worth mentioning that a note carries no semantic impact, i.e. the content
of a note does not in any way change the meaning or significance of the model
to which it is attached.
4. Extensibility Mechanisms:
The extensibility mechanisms allow you to customize and extend the UML by
adding new building blocks, creating new properties, and specifying new
semantics in order to make the language suitable for your specific problem
domain. There are three common extensibility mechanisms that are defined by
the UML: stereotypes, tagged values, and constraints.
Stereotypes:
Stereotypes allow you to extend the vocabulary of the UML so that you can
create new model elements, derived from existing ones, but that have specific
properties that are suitable for your problem domain. They are used for
classifying or marking the UML building blocks in order to introduce new
building blocks that speak the language of your domain and that look like
primitive, or basic, model elements. For example, when modeling a network
you might need to have symbols for representing routers and hubs. By using
stereotyped nodes you can make these things appear as primitive building
blocks. As another example, let us consider exception classes in Java or C++,
which you might sometimes have to model. Ideally you would only want to
allow them to be thrown and caught, nothing else. Now, by marking them with
a suitable stereotype you can make these classes into first class citizens in your
model; in other words, you make them appear as basic building blocks.
Stereotypes also allow you to introduce new graphical symbols for providing
visual cues to the models that speak the vocabulary of your specific domain
(see fig 4). Return copy of self Fig 2. Note 4 graphically, a stereotype is
rendered as a name enclosed by guillemots and placed above the name of
another element (see fig 3). Alternatively, you can render the stereotyped
element by using a new icon associated with that stereotype (see fig 4).

College
20
Tagged Values
Tagged values are properties for specifying keyword-value pairs of model
elements, where the keywords are attributes. They allow you to extend the
properties of a UML building block so that you create new information in the
specification of that element. Tagged values can be defined for existing model
elements, or for individual stereotypes, so that everything with that stereotype
has that tagged value. It is important to mention that a tagged value is not
equal to a class attribute. Instead, you can regard a tagged value as being a
metadata, since its value applies to the element itself and not to its instances.
One of the most common uses of a tagged value is to specify properties that
are relevant to code generation or configuration management. So, for example,
you can make use of a tagged value in order to specify the programming
language to which you map a particular class, or you can use it to denote the
author and the version of a component. As another example of where tagged
values can be useful, consider the release team of a project, which is
responsible for assembling, testing, and deploying releases. In such a case it
might be feasible to keep track of the version number and test results for each
main subsystem, and so one way of adding this information to the models is to
use tagged values. Graphically, a tagged value is rendered as a string enclosed
by brackets, which is placed below the name of another model element. The
string consists of a name (the tag), a separator (the symbol =), and a value (of
the tag) (see fig 6)
Constraints :

College
21
Constraints are properties for specifying semantics and/or conditions that must
be held true at all times for the elements of a model. They allow you to extend
the semantics of a UML building block by adding new rules, or modifying
existing ones. For example, when modeling hard real time systems it could be
useful to adorn the models with some additional information, such as time
budgets and deadlines. By making use of constraints these timing
requirements can easily be captured. Graphically, a constraint is rendered as a
string enclosed by brackets, which is placed near the associated element(s), or
connected to the element(s) by dependency relationships. This notation can
also be used to adorn a model elements basic notation, in order to visualize
parts of an elements specification that have no graphical cue. For example,
you can use constraint notation to provide some properties of associations,
such as order and changeability (see fig 7).
LIVE TRAFFIC INDEX

Live Traffic Index(LTI) is a project which enables users to find out the
destination route with out trsffic.
PROBLEM STATEMENT:
The online shortest path problem aims at computing the shortest path based on
live traffic circumstances. This is very important in modern car navigation
systems as it helps drivers to make sensible decisions. To our best knowledge,

College
22
there is no efficient system/solution that can offer affordable costs at both

client and server sides for online shortest path computation. Unfortunately, the
conventional client-server architecture scales poorly with the number of
clients. A promising approach is to let the server collect live traffic
information and then broadcast them over radio or wireless network. This
approach has excellent scalability with the number of clients. Thus, we
develop a new framework called live traffic index (LTI) which enables drivers
to quickly and effectively collect the live traffic information on the
broadcasting channel. An impressive result is that the driver can
compute/update their shortest path result by receiving only a small fraction of
the index. Our experimental study shows that LTI is robust to various
parameters and it offers relatively short tune-in cost (at client side), fast query
response time (at client side), small broadcast size (at server side), and light
maintenance time (at server side) for online shortest path problem.
Objective:
To the best of our knowledge, this is the first work to give a thorough cost
analysis on the hierarchical index techniques and apply stochastic process to
optimize the index hierarchical structure.
Purpose:
Our main purpose for this project is people invest their money to get
maximum profit and knowledge about our online trading system. Here all type
of user can go and analyses the data of different field and get maximum profit
for future investment.
Scope:

College
23
The scope of this project is to make user bid from anywhere any time.
Customer should have valid user-id and password to log into the system.
Admin can take back up of database for every auction that is happening.
WEEK-1
Find the following for a given application
1. Actors
2. Use cases with each actor
3. Extended or uses use cases (if applicable)
1.Actors
Actors found in the Online Auction System are: ADMIN, BUYER/SELLER
admin
Buyer/seller
2. Use cases with each actor:

College
24
Use case of admin:
login
assocation
Add /delete products
admin
View products
logout
Use case of user:
register
assocation
Buyer/seller
login
Search/view product
Buy product
Sell Product

College
25
3. Extended or uses use cases:
Extend use case of Buyer/Seller:

College
26
Prabhu:buyer/seller
<<
in
clu
de
s>
>
bu

College
assocation
27
Extend use case of admin:

College
28
Week 2
1. Identifying Scenarios from Use Case Dialog
2. Describing Use Case Scenarios
3. Finally draw the main use case diagram
1. Identifying Scenarios from Use Case Dialog:

Use case related to Buyer
Use case related to Seller
Use case related to Admin
2. Describing Use Case Scenarios:

a. Use case related to Buyer

College
29
Use case name:
Buy product
Primary Actor:
Buyer
Pre-condition:
Internet Connection
Main scenario:
1.Buyer register in to online auction

system
.
2. After registration he is allowed to
enter in to the system with his
authentication
id
provide
in
registration.
3. Search for the product form the list
of products available and selects to buy
it.
4. Search his history if interested buys
the product.
b. Use case related to Seller:

Use case
Sell product
Primary Actor:
Seller
Pre-condition:
Internet Connection and Registration
Main scenario
1. Seller enters into the system with the

id provide while registration (login).
2. Add product in to the system
3. Add information and details about the

College
30
product.
4.Updates the information about the
product
C.Use case related to Admin:
Use case
Admin
Primary Actor:
Admin
Pre-condition:
Admin logged in
Main scenario
1. Admin watches users and their

products.
2. Admin provides review
products for sellers and buyers.
of
3. Add the products to the list of

items after verification.

College
31
4. Deletes the items if not used for

long form the request of user.
5. Add or Remove users if not their
details are not accurate.
3. Finally draw the main use case diagram

College
32

College
33
Week 3
1. Create an Entity Relationship Diagram (ERD) for a given application.
2. For a sample application create a Data Flow Diagram
1. Entity Relationship Diagram (ERD):
An entity-relationship diagram (ERD) is a data modeling technique that
graphically illustrates an information systems entities and the relationships
between those entities. An ERD is a conceptual and representational model of
data used to represent the entity framework infrastructure.
The elements of an ERD are:
Entities
Relationships
Attributes
Steps involved in creating an ERD include:
Identifying and defining the entities
Determining all interactions between the entities
Analyzing the nature of interactions/determining the cardinality of the
relationships
Creating the ERD
Symbols used in ER diagram are:
Entity
Attribute
Weak Entity
Key Attribute
RelationshipWeak Entity Relationship

College
34
Multivalve AttributeComposite Attribute
The Entities in this application are: 1.Customer

2. Products
3. Buyer
4. Seller
5. Product History
The attributes of Customer are:
1.C_id
2. Cname.
The attributes of Product are:
1.Pid
2. Pname
3. Description
The attributes of Buyer are:
1.Bid
2. Bname
The attributes of Seller are:
1.Sid
2. Sname
Relationships identified: 1. Participate bidding (customer, products)

2. Feedback (buyer, products)
Relationships identified is Many too Many.
Ternary relationship between Buyer, Product History and Products.
ER DIAGRAM:

College
35
Pnamee
c_id
C_Name
P_id
Description
Participate bidding
Products
customer
Sname
Buyer
Seller
Sid
Feedback
Bid
Bname
Bid
PID
Product History
Feedback
PID
2. Data Flow Diagram:

A data flow diagram (DFD) illustrates how data is processed by a system in
terms of inputs and outputs. As its name indicates its focus is on the flow of
information, where data comes from, where it goes and how it gets stored.

College
36
Data flow diagrams became popular in the 1970s in software development.

They were first described in a classic text about Structured Design written by
Larry Constantine and Ed Yourdon. Yourdon & Coad's Object Oriented
Analysis and Design (OOA/OOD) was a way of visualizing software systems
before UML diagrams.
Symbols used in the DFD:
DFDs only involve four symbols. They are:
Process
Data Object
Data Store
External entity
Process
Transform of incoming data flow(s) to outgoing flow(s).
Data Flow
Movement of data in the system.
Data Store
Data repositories for data that is not moving. It may be as simple as a buffer or
a queue or a sophisticated as a relational database.
External Entity
Sources of destinations outside the specified system boundary.

Levels of DFD diagram:
The DFD may be used for any level of data abstraction. DFD can be
partitioned into levels. Each level has more information flow and data
functional details than the previous level.

College
37
Highest level is Context Diagram. Some important points are:

1 bubble (process) represents the entire system.
Data arrows show input and output.
Data Stores NOT shown. They are within the system.
Next Level is Level 0 DFD. Some important points are:
Level 0 DFD must balance with the context diagram it describes.
Input going into a process is different from outputs leaving the
process.
Data stores are first shown at this level.
Next level is Level 1 DFD. Some important points are:
Level 1 DFD must balance with the Level 0 it describes.
Inputs going into a process are different from outputs leaving the
process.
Continue to show data stores.
Rules
In DFDs, all arrows must be labeled.
The information flow continuity, that is all the input and the output to
each refinement, must maintain the same in order to be able to produce
a consistent system.

College
38
Context Level Data flow diagram:
Level-1 Data flow diagram:

College
39
WEEK-4
1. Take two of the use cases from week 1 application and write flow of
events for those.
2. Practice activity diagram from the example used.
1.Flow of events:
PARTICIPATION OF USER IN BIDDING:

Name
Registration

College
40
Primary Actor:
Seller/Buyer
Flow of Events
1. User login to the system with his login

id and password
2. User may be seller or buyer , if it is
seller after validation user selects seller
or buyer.
3. Seller will post the products and add
description about the product.
4. Seller communicates with the Buyer
who won the bidding.
5. Bidder searches the product check
whether the product is available or not.
6. If the product is available then he bids
the product along with the other buyers.
7. If the buyer invest highest amount
than other buyers then he won the
budding.
8. Bidder communicates with the Seller.
Entry-condition:
Online auction web portal through

Internet Connection
Exit-condition:
Quality Requirements
No internet connection
Connection lost at server
Good internet connection
Good server connection
2. Activity diagram:

College
41
Week 5
Write Software Requirement Specification (SRS) for a given application
SOFTWARE REQUIREMENT SPECIFICATION

College
42
1.1 INTRODUCTION:
Since the internet has become a popular place to buy and sell goods, online
auctioning services have made their way into most homes. On line auction system is web
based application, so the main advantage is that there is no more system compatibility
requirement problem. The main advantage of the online auction system is that the user can
have the varied classes for their investment, and through this system user can invest in their
own selected firm.
1.2 PROBLEM STATEMENT

Online Auction System represents an alternative process which is an increasingly
significant channel e-commerce. Unlike a conventional single seller buyer trading
procedure, online auction are inherently interactive and open to multiple participants from
various geographical areas. In general the participants can involve in auction is manual ,
which is very time effective , if the participants are late for the auction than he may miss his
product in which he want to buy. On making the process online the customers can
participate from anywhere and he can buy the products he wants that are provided by the
authority person.
1.3 PROJECT DESCRIPTION

1.3.1 Objective:
The objective of this project is to provide user to sit from anywhere and can participate in
the auction system and to notify the user about auction specification product info and to
give the feedback option for the products that has sold to encourage the seller and buyer.
1.3.2 Purpose:
Our main purpose for this project is people invest their money to get maximum profit and
knowledge about our online trading system. Here all type of user can go and analyses the
data of different field and get maximum profit for future investment.
1.3.3 Scope:
This Project investigates the entry threshold for providing a new auction service channel
via the real options approach, where the entry threshold is established by using an Online

College
43
auctioning system designed for the use of normal users(individuals), Industrialists,

Entrepreneurs, Organizations and Academicians under transaction rate uncertainty.
-
Customer must have a valid User Id and password to login to the system
If a wrong password is given three times in succession, that account will be

locked and the customer will not be able to use it. When an invalid password is
entered a warning is given to the user that his account is going to get locked.
After the valid user logs in he is shown the list of accounts he has with the bank.
On selecting the desired account he is taken to a page which shows the present
balance in that particular account number.and the details of what is latest auctions
are running currently.
1.3.3Overview:
This system provides an easy solution to users to buy or sell their product with maximum
profit online.
2.1 EXISTING SYSTEM

The existing "OPEN Auction House" is managed manually. Prior to each auction, the day
of auction, the venue and the items on auction are announced through news media. Those
who wish to take part in the auction have to arrive at the venue on that day on time. This
conventional method most of the times prevent aspiring bidders from participating in the
bidding process. Another headache of the old system is to track each bidding process and to
make it culminate in financial settlement. So the system has to keep records of both buyers
and sellers until the end of settlement. The process is very cumbersome and time
consuming.
2.2 PROPOSED SYSTEM

The slogan of the new site is AAA, 'Anyone, Anytime, Anywhere'. That what it really is
The "U Auction" is online auction house so the seller or bidder doesn't need to go anywhere,
instead they can take part in the auction just sitting in the comfort of their living room, be it during
the
day
or
night.
The proposed computerized "U Auction" site has made auction process simple. The only
5 pre-condition is that the user must register and authenticate before he/she can take part in the

College
44
bidding process. The system uses HTTP forms authentication which creates a session cookie for any
signed in user. Throughout the span of the session the cookie remains valid until the user logs out.
An auction house needs to have products to auction, so in the proposed system this is done using
product registration module. The module is open to user who is registered sellers and they need to
authenticate before they register any product. The system controls the closing date by adding 14
days to the submitting date there by restricting the bidding process to go on indefinitely .
Another important module in the proposed project is the "Bidding module ". Here one can
see the details of any particular product and also the bidding history. The user can bid on
that item by entering any amount greater than or equal to the incremental bid amount. Here
also system checks to see whether the user has his credential verified otherwise he/she will
be directed
to
the
login/registration
page.
The last but the least module is the "Web Administration" module. The module is
only open to the web administrator due to security reasons. In this module the administrator
can add product categories; this is to avoid rampant creation of categories. The 2nd thing is
the option to edit any given product. This will be necessary when some of the details of the
product need to be edited for one reason or other. The 3rd and last the closed bid manager
where the administrator notifies both the seller and buyer the need to complete the
transaction.
There is another module which runs more or less like background process. The function of
the module is to close bid of those products whose closing date is less than the current date.
The process is automatic and hidden from the web users.
2.3 Overall Description:

Product Perspective
The online auction system is an independent system.this system involves two users i.e buyer and
seller. The Database connection is provided online to make faster and easy acess to data retrieval.
Product Functions
-
Customer must have a valid User Id and password to login to the system.
If there is a new user he has to register for this auction process.
If a wrong password is given three times in succession, that account will be locked and
the customer will not be able to use it. When an invalid password is entered a warning is
given to the user that his account is going to get locked.
User can search the product he want and also in the particular price he wants i.emaximum and minimum price.
User can view his monthly as well as annual auctions. He can also view future auctions.

College
45
-
Administrator can take a back up of the database for every auction that is happening,
periodically.
All users are authenticated to avail the services
FAQ section is also included for end users benefit.
2.4 FUNCTIONAL REQUIREMENTS

Administrator: He is the super user responsible for managing clients of the
system, taking system
backup, generating reports, maintaining organization
details.
Manage Clients: The Administrator assigns new users when a new client joins
the online auctioning. Also he can delete an account when any of the user leave
the auctioning organization.
Maintain Corporate Details: The Administrator maintains entire details of the
Corporate that includes details of the Corporate Admin and its sub users details
etc.
Take System Backup: The Administrator Backup the database in order to
prevent loss of data on system crashes. He can backup entire database or a
particular section..
Generate Reports: : Responsible for checking the logs of different system
users for auditing and maintaining the integrity of the system.
2.5Nonfunctional requirements:
Usability:
Usability of the application can be of critical importance. As discussed above the user can
be of variety of needs. There should distinct categories, so as it becomes clear to user what
exactly he is looking for. Advanced search is of critical in this regard. Also it is important to
have a high performance (seed of website). If the system is live auction then the 'Client side
event handling' should be done with very advanced libraries and with great safety features.
There is separate article on Usability in this website.
Reliability:
The reliability percentage shown is based on the bids of the last 30 days. Only auctions that
have been confirmed to have been successfully won are counted as successes. Sometimes

College
46
an auction is successfully won but not confirmed as such by the system and incorrectly
counted as a failure. In other words, actual reliability can be higher than the percentage
shown but never lower. All bid failures are investigated to find the cause and prevent the
failure from occurring again to improve reliability. Bids that fail for reasons such as being
outbid, having an invalid username or password or being blocked from bidding by the seller
or by eBay are not counted as failures.
Performance:
The effectiveness of the bidder agents will depend on the proportion of time that their price
information is accurate. Maintaining such accurate information places stringent
performance requirements on the underlying infrastructure. Moreover the scalability of
such systems, in terms of the number of bidder agents that can be satisfactorily
accommodated, could be severely limited by the performance of the network. From the
point of view of accessibility it is important that such auction systems use existing
infrastructure, i.e. the Internet, and so the ability to directly address performance problems
may be limited. However, in this paper we consider how such performance limitations may
be circumvented, by incorporating active nodes within the network
Supportability:
One user can do a more than one bid on products. After completion of bidding process all
the bids are check and the product will give to that customer for purchase who has a high
bid price. The bidding exercise will have a specified opening and closing time. The EAuction will close when no new bids are received and the closing time has expired. If
however, a new (lower) bid is received just before the Scheduled closing time, the allocated
bidding time will be extended. User can also give their feedbacks about on this project.
There would be Three type of feedback which user can give they would be negative,
positive.
Implementation:
Implementation includes all those activities that take place to convert from the old system
to the new. The old system consists of manual operations, which is operated in a very
different manner from the proposed new system. A proper implementation is essential to
provide a reliable system to meet the requirements of the organizations. An improper
installation may affect the success of the computerized system. The implementation plan
includes a description of all the activities that must occur to implement the new system and
to put it into operation. It identifies the personnel responsible for the activities and prepares
a time chart for implementing the system.
Interface:

College
47
Application is broken into three separate logical layers, each with a well - defined set of
interfaces. The first tier is referred to as the presentation layer and typically consists of
graphical user interface of some kind. The middle tier, or business layer, consists of
application or business layer and the third layer- the data layer contains the data that is
needed for the application. The middle tier is basically the code that the user calls upon to
retrieve the desired data. The presentation layer then receives the data and formats it for
display. This separation of application logic from the user interface adds enormous
flexibility to the design of application. The third tier contains the data that is needed for the
application.
3.1 SCENARIOS:
Use case related to Buyer:

Use case name:
Buy product
Primary Actor:
Buyer
Pre-condition:
Internet Connection
Main scenario:
1.Buyer register in to online auction

system
.
2. After registration he is allowed to
enter in to the system with his
authentication id provide in registration.
3. Search for the product form the list
of products available and selects to buy
it.
4. Search his history if interested buys
the product.
Use case related to Seller:

Use case
Primary Actor:
Pre-condition:
Sell product
Seller
Internet Connection and Registration
Main scenario
1. Seller enters into the system with the

id provide while registration (login).

College
48
3. Add information and details about the

product.
product
Use case related to Admin:

Use case
Primary Actor:
Pre-condition:
Main scenario
Sell product
Seller
Internet Connection and
Registration
1. Seller enters into the system with
the id provide while registration
(login).
3. Add information and details about
the product.
product
3.2 USECASE MODEL

A use case is a coherent piece of functionality that a system provides interacting
with actors. It describes a system which involves a set of use cases and a set of

College
49
actors.A use case diagram summarizes who uses our application or system and what
they can do with it.
By use case model we can achieve:
The scenario in which our application interacts with people, organizations or
external systems.
The goals that it helps those actors to achieve.
The scope of our system.
WE MAINLY DISCUSS ABOUT USE CASE DIAGRAM IN USE CASEMODEL
3.3 OBJECT MODEL:

The object model visualizes the elements in a software application in terms of
objects.
An object is a real-world element in an objectoriented environment that may have a
physical or a conceptual existence.
It helps the users to get a perfect idea of the system. Objects can be modeled
according to the needs of the application. An object may have a physical existence,
like a customer, a car, etc.; or an intangible conceptual existence, like a project, a
process, etc.
WE MAINLY DISCUSS ABOUT CLASS AND OBJECT DIGRAMS IN OBJECT
MODEL.
3.4 DYNAMIC MODEL

Dynamic model gives detail behavior of how the system works.
We use different behavioraluml diagrams to clearly observe this.
It helps the users to get a perfect idea of the system.
WE MAINLY DISCUSS ABOUT SEQUENCE, ACTIVITY, COLLABRATION
AND STATECHART DIAGRAMS IN DYNAMIC MODEL.
3.5 SOFTWARE AND HARDWAREREQUIREMENTS:

College
50
Software Interfaces
-
User on Internet
: Web Browser, Operating System (any)
Application Server
: WAS
Data Base Server
: DB2
Network
: Internet
Development Tools
: RAD (J2EE,JavaScript,JSP,HTML), DB2.
Communication Interfaces
-
Client on Internet will be using HTTP/HTTPS protocol.
Client on Intranet will be using TCP/IP protocol.
A Web Browser such as IE 6.0 or equivalent.
Hardware interfaces
-
Processor
: Pentium 3 or above
Clock speed
: 800Mhz
System bus
: 32 bit
Ram : 256 MB or more
HDD : 40 GB
Monitor
: SVGA color
Keyboard
: 101 Keys
Modem
: 56 Kbps/ADSL broadband
Mouse : PS2/serial
FDD : 1.44 MB

College
51
Week 6
Build Sequence diagrams from the Scenarios
SEQUENCE DIAGRAM:

College
52
Step-1:Buyer/Seller register in to auction system

Step-2:Buyer/Seller log into the system after authentication
Step-3:Buyer searche for product to bid
Step-4:Seller posts the product into auction system and add
discription
Step-5:Byuer bids the product after he had successfully required
his product

College
53
Week 7
Build an Activity Diagram from a Use Case Narrative
Step-1:User log into the system with login id

College
54
Step-2:Checks the validity of the ID and password , if valid then the user
may be Buyer or Seller
Step-3:If the user is Seller then he post the product and add discription
about the product
Step-4:If the user is Buyer then he search the product checks the
avaliability
Step-5:If the product is avaliable then he bid with high value
Step-6:Seller and Buyer will communicates with each other about the
product

College
55
Week 8
Build a State Chart Diagrams from Sequence Diagrams
STATE CHART DIAGRAM:

College
56
State-1 :Buyerr gets login

State-2:Request for product
State-3:Avaliable product is avaliable with details buyer read it
State-4:If the Buyer is not satisfied with the product description then he
logout
State-5:If buyer is satisfied with description then he bid the product
State-6:If the bid value is low he disqualifies the bidding
State-7: If the bid value is high then he won it and communicates with
seller

College
57
Week 9
Think about any system and its components and draw
1 Deployment diagram.
2.Component diagram.
1.DEPLOYMENT DIAGRAM:
The nodes appear as boxes, and the artifacts allocated to each node appear as
rectangles within the boxes. Nodes may have sub nodes, which appear as
nested boxes. A single node in a deployment diagram may conceptually
represent multiple physical nodes, such as a cluster of database servers.
There are two types of Nodes:
1. Device Node

College
58
2. Execution Environment Node
2.COMPONENT DIAGRAM:
A component is something required to execute a stereotype function.

Examples of stereotypes in components include executables, documents,
database tables, files, and library files.
In this application we will be using the java for the development of the
application so we use .java executable files.

College
59
WEEK-10
ARENA CASE STUDY
In this section, we apply the concepts and methods described in this chapter to the ARENA
system.We start with the use case model and the glossary developed in the previous chapter.
We identifyparticipating entity, boundary, and control objects, and refine them by adding
attributes andassociations to the analysis object model. Finally, we identify inheritance
relationships and
consolidate the analysis object model. In this section, we focus primarily on the
AnnounceTournament use case.
5.6.1 Identifying Entity Objects
Entity objects represent concepts in the application domain that are tracked by the system.
We
use the glossary produced during elicitation as a starting point for identifying entity objects
in
ARENA. We identify additional entity objects and their attributes by applying Abbotts
heuristics
on the use cases. We initially focus only on noun phrases that denote concepts of the
application
domain. Figure 5-23 depicts the AnnounceTournament use case with the first occurrence of
noun
phrases we identified in bold.
Note that we identify entity objects corresponding to actors in the use case model. Actors
are concepts in the application domain and are relevant to the system (e.g., for access
control or

College
60
for documenting responsibilities or authorship). In ARENA, each legitimate LeagueOwner

is
represented with an object that is used to store data specific to that LeagueOwner, such as
her
contact information, the leagues that she manages, and so on.
Note, also, that not all noun phrases we identified correspond to classes. For example,
name of a tournament is a noun phrase referring to an attribute of the Tournament class.
List
of Advertisers is an association, in this case, between the League class and the Advertiser
class. We can use a few simple heuristics to distinguish between noun phrases that
correspond to
objects, attributes, and associations:

College
61
Attributes are properties. Attributes represent a single property of an object. They

represent a partial aspect of an object and are incomplete. For example, the name of an
Advertiser is an attribute that identifies an Advertiser. However, it does not include
other relevant information about the Advertiser (e.g., her current account balance, the
type of banners she advertises, etc.) that are represented by other attributes or
associations of the Advertiser class.
Attributes have simple types. Attributes are properties that often have types such as a
number (e.g., maximum number of Tournaments), string (e.g., the name of an
Advertiser), dates (e.g., the application start and end date of a Tournament).
Properties such as an address, a social security number, and a vehicle identification
number are also usually considered as simple types (and hence represented as
attributes) because users treat those as simple, atomic concepts. Complex concepts are
represented as objects that are related to other objects with associations. For example,
an Account is an object that is related to the corresponding Advertiser and can include
a balance, a history of transactions, a credit limit, and other similar properties.
Nouns referring to collections are associations, often with implicit ends. Lists, groups,
tables, and sets are represented by associations. For example, ARENA prompts the

College
62
LeagueOwner with a list of Advertisers that are potentially interested in exclusive

sponsorships. This concept can be represented with an association between the Arena
class and the Advertiser class, denoting which Advertisers are interested in
exclusive sponsorships. Often, the association end is implicit. For example, when
sponsorship issues are closed, ARENA prompts the LeagueOwner with a list of groups of
Players, Spectators, and Advertisers. We identify a new class, InterestGroup,
representing collections of users interested in new events about a league or a game.
Then, we identify an association between the Arena class and the InterestGroup class
(corresponding to the word list) representing all InterestGroups. Then, we identify
an association between the InterestGroup class and the Player, Spectator, and
Advertisers classes (corresponding to the word group). Finally, we identify
additional associations originating from the InterestGroup class to other classes
representing the interest of the users in the InterestGroup (i.e., League, Game).
Table 5-6 lists the entity objects, their attributes, and their associations that we identified
so far from the AnnounceTournament use case. We attach the attributes and associations to
their
relevant classes and write definitions for new classes. Writing definitions has several
purposes.
First, a name is not specific enough for all stakeholders to share the same understanding
about
the concept. For example, terms such as Game and Match can be interchanged in many
contexts.
In ARENA, however, they refer to distinct concepts (i.e., a Game represents a set of rules
enforced
by a piece of software, a Match represent a competition among a set of Players). Second,
objects identified during analysis correspond also to terms in the glossary we started during
elicitation. Stakeholders use the glossary throughout development to resolve ambiguities
and establish a standard terminology. Writing short definitions as classes are identified is
the best
way to prevent ambiguities and misunderstandings. Postponing the writing of definitions
results

College
63
in loss of information and in incomplete definitions.

Table 5-6 Entity objects participating in the AnnounceTournament use case identified from
noun
phrases in the use case. (?) denote areas of uncertainty that lead to the questions in Figure
5-24.

College
64
The identification of entity objects and their related attributes usually triggers additional
questions for the client. For example, when we identify implicit attributes and associations,
we
should double-check with the client to confirm whether our intuition was correct. In other
cases,
the ends of an association are ambiguous. We collect all the questions generated by the
identification of objects and go back to the client (or the domain expert). Figure 5-24
depicts the
questions we have after identifying entity objects participating in the AnnounceTournament
use
case.

College
65
5.6.2 Identifying Boundary Objects

Boundary objects represent the interface between the system and the actors. They are
identified
from the use cases and usually represent the user interface at a coarse level. Do not
represent
layout information or user interface details such as menus and buttons. User interface
mock-ups
are much better suited for this type of information. Instead, boundary objects represent
concepts
such as windows, forms, or hardware artifacts such as workstations. This enables
stakeholders to
visualize where functionality is available in the system.
Abbotts heuristics do not identify many boundary objects, as they are often left implicit
initially. Instead, we scan the AnnounceTournament use case (Figure 5-23) and identify
where
information is exchanged between the actors and the system. We focus both on forms in
which
actors provide information to the system (e.g., the form used by the LeagueOwner to create
a
Tournament) and on notices in which the system provides information to the actors (e.g., a
notice received by Advertisers requesting sponsorship). As with other objects, we briefly
define each class as we identify it. Table 5-7 depicts the boundary objects we identified for
AnnounceTournament with their definitions. Figure 5-25 depicts our additional questions.

College
66
Note that AnnounceTournament is a relatively complex use case involving several actors.
This yields a relatively large number boundary objects. In practice, a use case can have as
few as
a single boundary object to represent the interface between the initiating actor and the
system. In
all cases, however, each use case should have at least one participating boundary object
(possibly shared with other use cases).
5.6.3 Identifying Control Objects

Control objects represent the coordination among boundary and entity objects. In the
common
case, a single control object is created at the beginning of the use case and accumulates all
the
information needed to complete the use case. The control object is then destroyed with the
completion of the use case.
In AnnounceTournament, we identify a single control object called
AnnounceTournamentControl, which is responsible for sending and collecting notices to

College
67
Advertisers, checking resource availability, and, finally, notifying interested users. Note
that,
in the general case, several control objects could participate in the same use case, if, for
example, there are alternate flows of events to be coordinated, multiple workstations
operating
asynchronously, or if some control information survives the completion of the use case.
5.6.4 Modeling Interactions Among Objects
We have identified a number of entity, boundary, and control objects participating in the
AnnounceTournament use case. Along the way, we also identified some of their attributes
and
associations. We represent these objects in a sequence diagram, depicting the interactions
that
occur during the use case to identify additional associations and attributes.
In the sequence diagram, we arrange the objects we identified along the top row. We place
left-most the initiating actor (i.e., LeagueOwner), followed by the boundary object
responsible
for initiating the use case (i.e., TournamentForm), followed by the main control object (i.e.,
AnnounceTournamentControl), and the entity objects (i.e., Arena, League, and
Tournament).
Any other participating actors and their corresponding boundary objects are on the right of
the
diagram. We split the sequence diagram associated with AnnounceTournament into three
figures
for space reasons. Figure 5-26 depicts the sequence of interactions leading to the creation of
a
tournament. Figure 5-27 depicts the workflow for requesting and selecting an exclusive
sponsor.
Figure 5-28 focuses on the notification of interest groups.
The sequence diagram in Figure 5-26 is straightforward. The LeagueOwner requests the
creation of the tournament and specifies its initial parameter (e.g., name, maximum number
of

College
68
players). The AnnounceTournamentControl instance is created and, if resources allow, a

Tournament entity instance is created.
The sequence diagram in Figure 5-27 is more interesting as it leads to the identification of
additional associations and attributes. When requesting sponsorships, the control object
must
first obtain a list of interested sponsors. It requests it from the Arena class, which maintains
the
list of interested sponsors. This entails that the Arena class maintains at all times the list of
all
Advertisers, so that it can return this list to the AnnounceTournamentControl object (or
control
objects for other use cases that require the list of all Advertisers). To notify an Advertiser,
we
also may need contact information, such as E-mail address, or we may need to create a
mailbox

College
69
for notices within ARENA. Consequently, we add an contact attribute to the Advertiser
class,
which initially stores the E-mail address of the Advertiser until further devices are
supported.
Anticipating similar needs for other actors, we also add contact attributes to the
LeagueOwner
and Player classes.
When constructing the sequence diagram for notifying interest groups (Figure 5-28), we
realize that the use case does not specify how the selected sponsor is notified.
Consequently, we
add a step in the use case to notify all sponsors who replied about the sponsorship decisions
before interest groups are notified. This requires the identification of a new boundary
object,
SponsorNotice. The rest of the interaction does not yield any new discovery, as we already
anticipated the need for the InterestGroup and the InterestGroupNotice classes.
5.6.5 Reviewing and Consolidating the Analysis Model
Now that we have identified most participating objects, their associations, and their
attributes,
we draw UML class diagrams documenting the results of our analysis so far. As we have
identified many objects, we use several class diagrams to depict the analysis object model.
We
Figure 5-26 UML sequence diagram for AnnounceTournament, tournament creation
workflow.

College
70

College
71
use these class diagrams as a visual index into the glossary we developed. Although we
should
not expect the client or the users to be able to review class diagrams, we can use class
diagrams
for generating more questions for interviews with the client.
We first focus on the entity objects, since these need to be carefully reviewed by the client
as they represent application domain concepts (Figure 5-29). Note that we use the Arena
class as
a root object in the system; the Arena class represents a specific instantiation. For example,
given an instantiation, it is possible to get a list of all InterestGroups, Advertisers,
LeagueOwners, Games, and TournamentStyles by querying the Arena class. Moreover, note
that
objects are not shared among instantiations. For example, LeagueOwners belong to exactly
one
instantiation of the system. If a user is a LeagueOwner in several ARENA instantiations of
the
system, she holds a LeagueOwner account in each instantiation. We make these type of
choices
during analysis based on our interpretation of the problem statement, based on our
experience,
and based on resources available to build in the system. In all cases, these decisions need to
be
reviewed and confirmed by the client.
Next, we draw a class diagram depicting the inheritance hierarchies (Figure 5-30).
Although UML allows inheritance relationships and associations to coexist in the same
diagram,
it is good practice during analysis to draw two separate diagrams to depict each type of

College
72
relationship. First, the UML symbols used to denote each type are similar and easily
confused.

College
73
Second, analysts usually focus on inheritance and associations at different times. We will
see
later, in Chapters 6 through 10, that this is not the case during system design and object
design,
where it is often necessary to consider both relationships to understand how different
classes are
related.
Figure 5-30 shows three inheritance hierarchies. First, we identified an abstract class User
through generalization. This enables us to treat common attributes of various users in a
more
general fashion, including contact information and registration procedures. Note that in the
problem statement and in the use cases, we already used the term user, so we are simply
formalizing a concept that was already in use. We identified two other inheritance
hierarchies,
Game and TournamentStyle, identified through specialization to provide examples for both
concepts and to provide traceability to the problem statement. The TicTacToe and the Chess
classes are concrete specializations of Game that embody rules for the games called tic tac
toe
and chess, respectively. The KnockOutStyle and the RoundRobinStyle classes are
concrete
specializations of the TournamentStylethat provide algorithms for assigning Players to
knockout
tournaments (in which players need to win to remain in the tournament) and round robin
tournaments (in which each player plays all other players exactly once), respectively.
Finally, we draw a class diagram that depicts the associations among the boundary,
control, and selected entity objects associated with the use case (Figure 5-31). To generate
this
diagram from the sequence diagrams, we draw the equivalent communication diagram, with
the
control object to the left, the boundary objects in the center, and the entity objects on the
right.

College
74
We then replace the iterations with associations, where necessary, so that the objects in the
workflow can carry send messages to objects depicted in the sequence diagrams. We then
add
navigation to the associations to denote the direction of the dependencies: control and
boundary objects usually know about each other, but entity objects do not depend on any
control or
boundary objects.
Whereas the class diagram in Figure 5-29 focused primarily on the relationships among
application domain concepts, the class diagram of Figure 5-31 focuses on the concepts
associated with workflow of the use case at a coarse level. The control object acts as the
glue
among boundary and entity objects, since it represents the coordination and the sequencing
among the forms and notices. As indicated in the sequence diagrams in Figures 5-26
through
5-28, the control object also creates several of the boundary objects. The class diagram in
Figure 5-31 provides a summary of the objects participating in the use case and the
associations
traversed during the use case. However, the sequence diagrams provide the complete
sequencing
information of the workflow.

College
75
5.6.6 Lessons Learned

In this section, we developed the part of the analysis object model relevant to the
AnnounceTournament use case of ARENA. We started by identifying entity objects using
Abbotts
heuristics, then identified boundary and control objects, and used sequence diagrams to find
additional associations, attributes, and objects. Finally, we consolidated the object model
and
depicted it with a series of class diagrams. We learned that:
Identifying objects, their attributes and associations, takes many iterations, often with
the client.
Object identification uses many sources, including the problem statement, use case
model, the glossary, and the event flows of the use cases.
A nontrivial use case can require many sequence diagrams and several class diagrams.
It is unrealistic to represent all discovered objects in a single diagram. Instead, each
diagram serves a specific purposefor example, depicting associations among entity

College
76
objects, or depicting associations among participating objects in one use case.

Key deliverables, such as the glossary, should be kept up to date as the analysis model
is revised. Others, such as sequence diagrams, can be redone later if necessary.
Maintaining consistency at all times, however, is unrealistic.
There are many different ways to model the same application domain or the same
system, based on the personal style and experience of the analyst. This calls for
developing style guides and conventions within a project, so that all analysts can
communicate effectively.

College

OOSE

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

OOSE

Загружено:

Авторское право:

Доступные форматы

1

Velagapudi Ramakrishna Siddhartha Engineering

OBJECT ORIENTED SOFTWARE

DEPARTMENT OF INFORMATION TECHNOLOGY

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

6.1.3. Project Description

UNIFIED MODELING LANGUAGE (UML):

Velagapudi Ramakrishna Siddhartha Engineering

Unified Modeling Language

Velagapudi Ramakrishna Siddhartha Engineering

A model is a simplification of reality

1) BASIC BUILDING BLOCKS

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

Dependency is a relationship between two things in which a change to one

Velagapudi Ramakrishna Siddhartha Engineering

It is denoted by a solid line with a hollow arrow head pointing to the

Velagapudi Ramakrishna Siddhartha Engineering

1. STRUCTURAL DIAGRAMS(STATIC DIAGRAMS)

Velagapudi Ramakrishna Siddhartha Engineering

Component and Deployment diagrams are called as Physical Diagrams.

Velagapudi Ramakrishna Siddhartha Engineering

If sender object continues executing while target is processing the

Velagapudi Ramakrishna Siddhartha Engineering

D) STATE CHART DIAGRAM

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

b)SCOPE:The content that gives specific meaning to a name.

Velagapudi Ramakrishna Siddhartha Engineering

One of the most important kinds of adornments is a note. This is a graphical

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

LIVE TRAFFIC INDEX

Velagapudi Ramakrishna Siddhartha Engineering

there is no efficient system/solution that can offer affordable costs at both

Velagapudi Ramakrishna Siddhartha Engineering

2. Use cases with each actor:

Velagapudi Ramakrishna Siddhartha Engineering

Use case of admin:

Use case of user:

Velagapudi Ramakrishna Siddhartha Engineering

3. Extended or uses use cases:

Extend use case of Buyer/Seller:

Velagapudi Ramakrishna Siddhartha Engineering

Velagapudi Ramakrishna Siddhartha Engineering

Extend use case of admin:

Velagapudi Ramakrishna Siddhartha Engineering

1. Identifying Scenarios from Use Case Dialog:

2. Describing Use Case Scenarios:

Velagapudi Ramakrishna Siddhartha Engineering

Use case name:

1.Buyer register in to online auction

b. Use case related to Seller:

Internet Connection and Registration

1. Seller enters into the system with the

Velagapudi Ramakrishna Siddhartha Engineering

C.Use case related to Admin:

1. Admin watches users and their

3. Add the products to the list of

Velagapudi Ramakrishna Siddhartha Engineering