OOSE

1

Velagapudi Ramakrishna Siddhartha Engineering College

2

OBJECT ORIENTED SOFTWARE ENGINEERING LAB

Submitted By

L.VIJAYA VARMA

(148W1D5915)

Master of Technology

DEPARTMENT OF INFORMATION TECHNOLOGY


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


3

INDEXS.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 3Do the following for a given application

4.1.Draw Entity Relation Diagram

4.2.Draw Data Flow Diagram


5.1.Write Flow of Events for any of 2 use cases from week 1

5.2.Draw Activity Diagram


4

6. Week 5System Requirement Specification 6.1. Introduction

6.1.1. Characteristics of SRS

6.1.2. Problem Statement

6.1.3. Project Description

6.2. About Project

6.2.1. Existing System6.2.2. Proposed System6.2.3. Overview 6.2.4. Functional Requirements6.2.5. Non-Functional Requirements6.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 67.1.Draw Sequence Diagram for a given application


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


5

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.

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


6

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?

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 BLOCKS2. RULES3. COMMON MECHANISMS

1) BASIC BUILDING BLOCKS There are three kinds of basic building blocks. They are:

i. THINGSii. RELATIONSHIPS

iii. DIAGRAMSi. THINGS IN UML:

There are four kinds of things in UML. They are:

STRUCTURAL THING BEHAVIOURAL THINGS ANNOTATIONAL THINGS


Student 1

7

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.

Class Name

Attributes

Operations()

b) INTERFACE An Interface is a collection of operations that specify a service of a class

or component

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.

UseCaseActor

e) ACTIVE CLASS Active class is just like a class but its elements are connected to other

class elements.


Component

8

f) COMPONENT Component represents physical packaging of logical elements like

classes, interfaces and collaborations.

g) NODE A Node is physical element that exists at run-time and having at least

some memory and processing capability.

Node

BEHAVIORAL THINGSBehavioral 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.


9

ANNOTATIONAL THINGSAnnotational Things are explanatory parts of UML. Only 1 type.NOTE

Note is used to give comments to an element or collection of elements.

Note

GROUPING THINGSGrouping Things are the organizational parts of the model. Only one typePACKAGE

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()

ChannelDependency

b) ASSOCIATION : It is denoted by a solid line.

____________________


10

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 :It is denoted by a solid line with a hollow arrow head pointing to the parent

GeneralizationGeneralization is a relationship in which the child will share the behavior of the parent.

Shape

origin : Integer

display()

Rectangle

length : Integerbreadth : 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


11

There are 9 types of Diagrams in UML, which are classified into 2 types

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.

Staff

S_name : String

College

name : Stringlocation : String

collect fees()recruit faculty()

Department

D_name : StringD_code : Integer

b) OBJECT DIAGRAMAn Object diagram shows a set of objects and their relationships. They

represent snapshots of instances of the things found in class diagrams.

S: Staff

S_name = "xyz"

C: College

name = "B.V.R.I.T"location = "Narsapur"

collect fees()recruit faculty()

D: Department

D_name = "CSE"D_code : Integer = 05

c) COMPONENT DIAGRAMA Component diagram shows the organizations and dependencies among

a set of components.


12

d) DEPLOYMENT DIAGRAMA 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 DIAGRAMA 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 DIAGRAMSAn 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


13

A Sequence diagram is an interaction diagram that emphasizes the time-ordering 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.


14

C)COLLABORATION DIAGRAM A Collaboration diagram is an interaction diagram that emphasizes the

structural organization of the objects that send and receive messages.

S: Student A: Admin

1: Request form

2: give form

3: fill form

4: submit

5: check form

6: eligible

D) STATE CHART DIAGRAMA 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.


15

E) ACTIVITY DIAGRAMAn 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 circleFinal Activity: This shows the end of the flow in the activity diagram. It is denoted by a solid circle nested in a circle.


16

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

Listen Watch

Success

Forking

Joining

synchronization bar

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 diagramsb)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.


17

e)EXECUTION:To run a model.2) LESS-WELL FORMED RULES:

These are of 3 typesa)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 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


18

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 element’s 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

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


19

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).

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


20

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 :

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 element’s basic notation, in order to visualize parts of an element’s 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).


21

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,

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


22

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:

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


Buyer/seller

Add /delete products

login

View products

admin

logout

assocation

23

admin

2. Use cases with each actor:

Use case of admin:

Use case of user:


login

register

Search/view product

Buy product

assocation

Sell Product

24

3. Extended or uses use cases:

Extend use case of Buyer/Seller:


Buyer/seller

assocation

mobile number

user name

register

emailid

<<include>>

<<include>>

<<include>>

user name

password

login

<<include>>

<<include>>

car

Sell

House

<<extend>>

car

buy<<includes>>

25


Prabhu:buyer/seller

26

Extend use case of admin:

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


27

Use case related to Admin

2. Describing Use Case Scenarios:

a. 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.

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


28

id provide while registration (login).

2. Add product in to the system

3. Add information and details about the 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 of products for sellers and buyers.


29

3. Add the products to the list of items after verification.

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


30

Registration

Login

Search/View Product

Sell Product

Biding for a Product

Manage Product

Logout

Online Auction

Administrator

Seller

Buyer


31

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 system’s 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 Weak Entity

Attribute Key Attribute

RelationshipWeak Entity Relationship


32

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.


33

ER DIAGRAM:

2. Data Flow Diagram:


customer ProductsParticipate bidding

c_id C_Name

Description

Pnamee

P_id

BuyerSname

Sid

BnameBid

Seller

Feedback

Product History

Bid PID

FeedbackPID

34

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.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:


35

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.

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.

Context Level Data flow diagram:


36

Online Auction System

Seller Buyer

Post The Product

View the Auction Updates

Search the Product

View Products

Level-1 Data flow diagram:

1.Registration

2.Login

3.Search/view all

Product

4.Sell the Product

5.Bidding the

Product

6.Conformation

Bidding(communication)

Seller Buyer

sign up

Conformation

Sign up

Conformation

Statues Update

Post Product

Communication Communication

Search Product

View Product

Product

Modify

Modify

Fet

ch

Fetch Fetch

Customer

Modify


37

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

Primary Actor: Seller/Buyer

Flow of Events 1. User login to the system with his login id and password2. 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: No internet connection Connection lost at server


38

Quality Requirements Good internet connection Good server connection

2. Activity diagram:

Login

Valid

User type

Post Product Search Product

Check Product Availability

Biding

Max bid

Buy Product

Communication

Inval

id id

/pas

swor

d

valid id&password

Buyer

no

Seller

yes

yes

no

Communication with winer Buyer


39

Week 5

Write Software Requirement Specification (SRS) for a given application

SOFTWARE REQUIREMENT SPECIFICATION

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.


40

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

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 only5 pre-condition is that the user must register and authenticate before he/she can take part in the 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.


41

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.e- maximum

and minimum price.

- User can view his monthly as well as annual auctions. He can also view future auctions.

- 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.


42

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 user’s 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 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.


43

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 E-Auction 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:

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.


44

3.1 SCENARIOS:

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 Buyer:

Use case related to Seller:

Use case Sell productPrimary Actor: SellerPre-condition: Internet Connection and Registration

Main scenario 1. Seller enters into the system with the id provide while registration (login).





45

Use case related to Admin:

Use case Sell productPrimary Actor: SellerPre-condition: Internet Connection and

RegistrationMain scenario 1. Seller enters into the system with

the id provide while registration (login).




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 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.


46

An object is a real-world element in an object–oriented 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:

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


47

- 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

Week 6Build Sequence diagrams from the Scenarios


48

SEQUENCE DIAGRAM:

Buyer Auction System Seller

Registration

Conformation

Login

Authentication check

Search product

View product

Search product

Requirement

Suggestion

Bidding the product

Auction close

Auctiontime

expired

Registration

Conformation

Authentication check

Login

Post the product

Conformation

Post the product

Conformation

Final update status

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 productVelagapudi Ramakrishna Siddhartha Engineering College

49

Week 7

Build an Activity Diagram from a Use Case Narrative

Login

Valid

User type

Post Product Search Product

Check Product Availability

Biding

Max bid

Buy Product

Communication

Invali

d id/

pass

word

valid id&password

Buyer

no

Seller

yes

yes

no

Communication with winer Buyer

Step-1:User log into the system with login id


50

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

Week 8


51

Build a State Chart Diagrams from Sequence Diagrams

STATE CHART DIAGRAM:

Login

Req. for Product

Details

Buying

Biding

Communication

Invalid User

Authentication User

Product Available

Req. satisfy

Req. Not satisfy

Low Bid

Max Bid

State-1 :Buyerr gets login


52

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

Week 9


53

Think about any system and its components and draw

1 Deployment diagram.

2.Component diagram.

1.DEPLOYMENT DIAGRAM:

Database Server

Web Server

Auction System

Auction System Auction System Auction System

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 Node2. Execution Environment Node

2.COMPONENT DIAGRAM:


54

Auction Management

User Detail

Manage

Product Detail

Bid Detail

Sold Detail

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.

WEEK-10


55

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 Abbott’s

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

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:


56

• 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


57

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

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


58

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

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.


59

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


60

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.

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.

Abbott’s 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


61

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.

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


62

AnnounceTournamentControl, which is responsible for sending and collecting notices to

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

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


63

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

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


64

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.


65

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


66

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


67

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

confused.

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


68

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.

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.


69

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

Abbott’s

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 purpose—for example, depicting associations among entity

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


70

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.


Documents

OOSE