Ur Project

1
MINI PROJECT REPORT

ON
WEATHER REPORT
Submitted in partial fulfillment of requirements to

ACHARYA NAGARJUNA UNIVERSITY
CS 451 – SE/MINI PROJECT LAB
BY
J.LAKSHMAN KUMAR (Y7CS859)

K.MADHU (Y7CS865)
K.SURYATEJA (Y7CS854)
October- 2010
R.V.R & J.C.COLLEGE OF ENGINEERING

(Approved by A.I.C.T.E)
(Affiliated to Acharya Nagarjuna University)
Chandramoulipuram : : Chowdavaram
GUNTUR – 522 019
2
R.V.R & J.C.COLLEGE OF ENGINEERING
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
BONAFIDE CERTIFICATE
Certified that this project work titled Weather Report is the bonafide work of
J.Lakshman kumar (Y7CS859), K.Madhu (Y7CS865), K.Suryateja (Y7CS854) who
carried out the work under my supervision, and submitted in partial fulfillment of the
requirements to CS-451 Software Enginnering/Mini Project Lab during the year 2010-
2011.
Mr. R. Mabubasha Dr. G.Satyanarayana Prasad

Lecturer Incharge Prof. & HOD, Dept. of CS
3
ACKNOWLEDGEMENT
The successful completion of any task would be incomplete without a proper

suggestion, guidance and environment. Combination of these 3 factors acts like backbone
to our mini project report on “WEATHER REPORT”.
We regard our sincere thanks to our principal Dr. P. S. SANKAR RAO sir for
proving support and stimulating environment. We would like to express our gratitude to
the management of R. V. R. & J. C. COLLEGE OF ENGINEERING for providing us
with a pleasant Environment and Excellent Lab faculty.
We are greatly indebted to our Professor and HOD, Dept., of Information

Technology Dr. G.Satyanarayana Prasad for his valuable suggestions during our
course period.
We express our sincere thanks to our Lecturer In charge, Mr. R.

MABUBASHA, MR. NAGARAJU, MR. PHANI KIRAN Lecturer in Department of
Information Technology for timely help, guidance and providing us with the most
essential materials required for the completion of this report.
J.Lakshman kumar(Y7CS859)
K.Madhu(Y7CS865)
K.Suryateja(Y7CS854)
4
CONTENTS
1. Problem statement 6
ANALYSIS
2. Requirements elicitation 7
3. System Requirements Specification 7

Use case view
4. Identification of Actors. 14
5. Identification of Use cases and sub use cases. 16
6. Building requirements model through Use case diagram. 19
7 . Flow of Events. 26
8. Prototypes for application. 30
9. Activity diagram. 31
Logical view
10. Identification of Analysis classes. 37
11. Identify the responsibilities of Classes. 43
12. Use case realizations. 49
13. Sequence diagrams. 53
14. Collaboration diagrams. 53
15. Identification of attributes and methods of classes. 57
16. Identification of relationships among classes. 58
17. UML Class diagram. 59

5
18. UML state chart diagram. 64
DESIGN
19. Designing classes by applying design axioms. 69
20. Refining attributes, methods & relationships. 70
21. Refined class diagram. 75
22. Implementation diagrams.
22. a. Component diagram. 76
22. b. Deployment diagram. 77
23. Testing
78
24. Implementation screen shots 80
25.Conclusion 87
References 88
6
1.PROBLEM STATEMENT
Problem Scenario:
Now a days we see in many cities and places there causes many disasters
due weather conditions. Even we can see so much loss of life, property and etc. The
purpose of this report is to push the boundaries of current research on climate change so
we may better understand the coming climatic conditions and can protect the life and
property.
Proposed Solution:
The idea is to generate a weather report that which is having the details about
the reports of the previous weather and present weather conditions. In this visitors visits
the weather report for finding weather conditions about the previous and present. The
administrator will maintain the complete weather database and he have a capability to
insert new report and update the previous values that were present in the weather
database.
The details, which are maintained in the database, are shown below:
1. Entry of the users.

2. What weather information required by user ?
3. Details of country,state,details,date weather information.
4.Administrator can update,delete,add weather information into the weather report
syetem.
5. Logout time of the borrower.
7
Database Administrator (administrator) will maintain the database of the system

(weather report). Once we scan the Weather Report system, the details will automatically
maintain in the system.
ANALYSIS
2.REQUIREMENTS ELICITATION
This section of the document lists required requirements for weather report.
 Managing the weather details.

 Managing the user reqiremtns.
 Inserting and updating the weather details in the database.
 Managing the administrator user name and passwords.
 Geting the weather details of the present and previous according to the
user reqirements.
 Deleting or modifing the data present in the weather database as per the
administrator wish.
3.SYSTEM REQUIREMENTS SPECIFICATIONS
HARDWARE:
PROCESSOR : PENTUIUM IV 2.6 GHz
RAM : 512MB DD RAM
MONITOR : 15” COLOR

8
HARD DISK :320 GB
CDDRIVE : LG52X
KEYBOARD : STANDARD 102 KEYS
MOUSE :3 BUTTONS
SOFTWARE:
FORNT END :JAVA,HTML,SERVLETS
BACKEND : ORACLE 10g
OPERATING SYSTEM : WINDOWS XP
HyperText Markup Language(HTML):
HyperText Markup Language (HTML), the publishing language of the

World Wide Web. This specification defines HTML 4.01, which is a subversion
of HTML 4. In addition to the text, multimedia, and hyperlink features of the
previous versions of HTML and HTML 2.0, HTML 4 supports more multimedia
options, scripting languages, style sheets, better printing facilities, and documents
that are more accessible to users with disabilities. HTML 4 also takes great strides
towards the internationalization of documents, with the goal of making the Web
truly World Wide. Publish online documents with headings, text, tables, lists,
photos, etc.Retrieve online information via hypertext links, at the click of a
button.Design forms for conducting transactions with remote services, for use in
searching for information, making reservations, ordering products, etc.Include
spread-sheets, video clips, sound clips, and other applications directly in their
documents.
The following general principles are observed when working with HTML
Separate structure and presentation:
Html has its roots in sgml ,which has always been a language for the
specification of structural markup. As HTML matures more and more of its
9
presentational elements and attributes are being replaced by other mechanisms, in

particular style sheets.
ACCESSIBILITY:
As the Web community grows and its members diversify in their abilities and skills, it is
crucial that the underlying technologies be appropriate to their specific needs. HTML has
been designed to make Web pages more accessible to those with physical limitations.
HTML 4 developments inspired by concerns for accessibility include:
1)Better distinction between document structure and presentation, thus encouraging the
use of style sheets instead of HTML presentation elements and attributes.
2)Better forms, including the addition of access keys, the ability to group form controls
semantically, the ability to group SELECT options semantically, and active labels.
3)The ability to markup a text description of an included object (with the OBJECT
element).
4)A new client-side image map mechanism (the MAP element) that allows authors to
integrate image and text links.
5)The requirement that alternate text accompany images included with the IMG element
and image maps included with the AREA element.
6)Support for the title and lang attributes on all elements.
7)Support for the ABBR and ACRONYM elements.
8)A wider range of target media (tty, braille, etc.) for use with style sheets.Better tables,
including captions, column groups, and mechanisms to facilitate non-visual
rendering.Long descriptions of tables, images, frames, etc.
INTRODUCTION ABOUT JAVA:
CREATION OF JAVA:
Java is a programming language originally developed by Jame Gosling at Sun

Microsystems (which is now a subsidiary of Oracle Corporation) and released in 1995 as
a core component of Sun Microsystems' Java platform. The language derives much of
its syntax from Cand C++ but has a simpler object model and fewer low-level facilities.
Java applications are typically compiled to bytecode(class file) that can run on any Java
10
Virtual Machine (JVM) regardless of computer architecture. Java is a general-purpose,

concurrent, class-based, object-oriented language that is specifically designed to have as
few implementation dependencies as possible. It is intended to let application developers
“write once, run anywhere". Java is currently one of the most popular programming
languages in use, and is widely used from application software to web applications.
JAVA Performance:
Programs written in Java have a reputation for being slower and requiring more
memory than those written in C. However, Java programs' execution speed improved
significantly with the introduction of Just-in-time compilation in 1997/1998 for Java
1.1,the addition of language features supporting better code analysis (such as inner
classes, StringBuffer class, optional assertions, etc.), and optimizations in the Java Virtual
Machine itself, such as HotSpot becoming the default for Sun's JVM in 2000.
To boost even further the speed performances that can be achieved using the Java
language Systronix made JStik, a microcontroller based on the aJile Systems line of
embeddedJava processors. In addition, the widely used ARM family of CPUs has
hardware support for executing Java bytecode through its Jazelle option.
JAVA IS PLATFORM INDEPENDENT:

In the classic sense of software development, programs are coded in higher
level languages such as C/C++, then that source code needs to be compiled into native
machine language specific to that platform so that the program is made executable.Java
compiler on the other hand does not compile Java source files into native machine
language, instead it compiles the source code into bytecodes. These bytecodes are
platform independant i.e. in other words specific to to the Java Virtual Machine
specification. This enables platform independant compilation. When the bytecode
compiled programs are executed thru the Java interpeter, it converts those bytecodes into
native machine code and executes them thru the JVM which is specific to host
environment it is running on. This enables platform specific execution.
JAVA IS ROBUST:
Java is robust because it is highly supported language, meaning that unlike C you
cannot crash your computer with a bad program. Also, another factor in its robustness is
its portability across many Operating systems, with is supported by the Java Virtual
Machine.
11
JAVA IS PORTABLE:
Java is known as a portable language because Java code can currently
execute on all major platforms. What's more, once you've compiled your Java source files
to .class files, those files can be used on any Java-supported platform without
modification, unlike many other languages.Because application sorfware written by
JAVA can run on any platform just with a JAVA compiler.Java compiler will compile
you java codes to byte-code,but not machine-code.So you can run it on every platform.
JAVA IS MULTITHREADED:
Multithreading is simply the ability of a program to do more than one thing at a
time. For example and application could be faxing documentation at the same time is
printing another document. Multithreading is particularly important in multimedia
program might often be running a movie, running a audio track and displaying text at the
same time.
JAVA IS EXTENSIBLE:
A big plus for java is the fact it can be extended. It was purposely written to
be lean with the emphasis on doing what it does very well: instead of typing of tryong to
do everything from beginning ,it was written so that extending it is very easy.
JAVA IS SECURE:
Java is considered more secure than other languages for several reasons:
• The Java compiler catches more compile-time errors; other languages (like
C++) will compile programs that produce unpredictable results.
• Java does not allocate direct pointers to memory. This makes it impossible
to accidentally reference memory that belongs to other programs or the
kernel.
12
JAVA DATABASE CONNECTIVITY(JDBC):
About jConnect for JDBC
jConnect is a 100% pure Java implementation of the JDBC standards. It provides Java
developers native database access in multi-tier and heterogeneous environments. Unlike
other JDBC implementations, you can download jConnect quickly, without client
installation. This makes jConnect both easier and more cost-effective for a new class of
thin-client Java applications. jConnect provides high-performance, direct access to the
complete family of Sybase products, including SQL Server, SQL Anywhere, Sybase
IQ, and Replication Server. Through OmniConnect, it provides high performance,
transparent connectivity to more than 25 enterprise and legacy database servers. jConnect
can also access Oracle, AS/400, and other database servers directly, using DirectConnect
.
Installing jConnect for JDBC
This CD includes the jConnect for JDBC Installation Guide and Release Notes in HTML
and Adobe Acrobat (.pdf) formats. The documentation files are located in the inst_doc
directory on the CD. You can access these files from the CD, or you can copy them to a
local drive. The jConnect for JDBC Installation Guide and Release Notes provide system
requirements and complete instructions for installing and testing the product, describes
features new to this release, and reports known problems.
SERVLETS USING JAVA WEBSERVER:
A servlet container uses a Java Virtual Machine* to run servlet code as requested by a
web server. The servlet container is also responsible for managing other aspects of the
servlet lifecycle: user sessions, class loading, servlet contexts (which we will discuss in
the next session), servlet configuration information, servlet persistence, and temporary
storage.
Servlet basics:
Servlet API consists of two packages, javax.servlet and javax.servlet.http. The javax is
there because servlets are a standard extension to Java, rather than a mandatory part of
the API. This means that while servlets are official Java, Java virtual machine developers
aren’t required to include the classes for them in their Java development and execution
environments. As mentioned already, however, the Servlet API is required for J2EE 1.3.
The HttpServlet class is an extension of GenericServlet that includes methods for
handling HTTP-specific data.* HttpServlet provides a number of methods, such as
doGet(), doPost(), and doPut(), to handle particular types of HTTP requests (GET, POST,
and so on). These methods are called by the default implementation of the service()
method, which figures out what kind of request is being made and then invokes the
appropriate method. Here’s a simpleHttpServlet:
13
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class HelloWorldServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType("text/html");
PrintWriter out = resp.getWriter();
out.println("<HTML>");
out.println(
"<HEAD><TITLE>Have you seen this before?</TITLE></HEAD>");
out.println(
"<BODY><H1>Hello, World!</H1><H6>Again.</H6></BODY></HTML>");
}
}
HelloWorldServlet demonstrates many essential servlet concepts. First,
HelloWorldServlet extends HttpServlet. This is standard practice for an HTTP servlet.
HelloWorldServlet defines one method, doGet(), which is called whenever anyone
requests a URL that points to this servlet.† The doGet() method is actually called by the
default service() method of HttpServlet.
Servlet Features:
The java web server provides several important servlet features. These
includes:
1. Loading and invoking servlets: servlets can be loaded both locally and remotely.
2. Filters and servlets chaining: the java web server uses mime typesto call servlets
sequentially.
3. Server-side includes: servlets can be invoked from dynamic HTML documents
using tags.
4. Replacing CGI script: servlets are on effective substitute for CGI script and
provide a faster and cleaner way to generate dynamic document.
14
Use-case view
4. IDENTIFICATION OF ACTORS
Actors represent system users. They are NOT part of the system. They represent
anyone or anything that interacts with (input to or receive output from) the system.
An actor is someone or something that:
• Interacts with or uses the system
• Provides input to and receives information from the system
• Is external to the system and has no control over the use cases
Actors are discovered by examining:
• Who directly uses the system

• Who is responsible for maintaining the system
• External hardware used by the system
• Other systems that need to interact with the system
The needs of the actor are used to develop use cases. This insures that the system will be
what the user expected.
GRAPHICAL DEPICTION:
An actor is a stereotype of a class and is depicted as a "stickman" on a use-case diagram.
For example,
15
Visitor
Naming
The name of the actor is displayed below the icon.
Questions to help to identify actors
1. Who is interested in a certain requirement
2. Where is the system used within the organization?
3. Who will benefit from the use of the system?
4. Who will supply the system with information, use this information, and remove
this information?
5. Who will support and maintain the system?
6. Does the system use an external resource?
7. Does one person play several different roles?
8. Do several people play the same role?
9. Does the system interact with a legacy system?
Actors identified are:
1) Administrator:
Administrator is a person who is responsible for inserting,deleting ,updatting
the values of weather inforamtion.
ADMINISTRATOR
2) Visitor:
The person who uses the weather information system to get inforamtion about
about present and past weathe informations.
Vistitor
16
5. IDENTIFICATION OF USE-CASES AND SUB USE-CASES
Use-case diagrams graphically represent system behavior (use cases).

These diagrams present a high level view of how the system is used as viewed from an
outsider’s (actor’s) perspective. A use-case diagram may contain all or some of the use
cases of a system.
A use-case diagram can contain:
 actors ("things" outside the system)
 use cases (system boundaries identifying what the system should do)
 Interactions or relationships between actors and use cases in the system including
the associations, dependencies, and generalizations.
Use-case diagrams can be used during analysis to capture the system requirements
and to understand how the system should work. During the design phase, you can use
use-case diagrams to specify the behavior of the system as implemented.
In its simplest form, a use case can be described as a specific way of using the system
from a user’s (actor’s) perspective. A more detailed description might characterize a use
case as:
 A pattern of behavior the system exhibits
 A sequence of related transactions performed by an actor and the system
17
 Delivering something of value to the actor.

Use case provides a means to:
 Capture system requirements
 Communicate with the end-users and domain experts
 Test the system.
Use cases are best discovered by examining the actors and defining what the
actor will be able to do with the system. Since all the needs of a system typically cannot
be covered in one use case, it is usual to have a collection of use cases. Together this use
case collection specifies all the ways of using the system.
Use case is a sequence of transactions performed by a system that yields a
measurable result of values for a particular actor. The use cases are all the ways the
system may be used.
The UML notation for use case is:
Log-In
The basic shape of a use case is an ellipse
• A use case may have a name, although it is typically not a simple name. It is often
written as an informal text description of the actors and the sequences of events
between objects. Use case names often start with a verb. For example, names of
possible use cases for an ATM machine might include Dispense Cash or Transfer
Funds.
• The name of the use case is displayed below the icon.
The set of questions used to identify the use-cases are:
1. What are the tasks of each actor?
2. Will any actor create, store, change, remove or read information in the system?
3. What use cases will create, store, change, remove, or read this information?
18
4. Will any actor need to inform the system about sudden, external changes?
5. Does any actor need to be informed about certain occurrences in the system?
6. What use cases will support or maintain the system?
7. Can all functional requirements be performed by the use cases?
Purpose of use cases:

 Well-structured use cases denote essential system or subsystem behaviors only,
and are neither overly general nor too specific.
 A use case describes a set of sequences, in which each sequence represents the
interaction of the things outside the system (its actors) with the system itself (and
its key abstraction).
 Use cases specify desired behavior; they do not dedicate how the behavior will be
carried out. It helps you to communicate with your developers (who build system
that satisfies your requirements) with out getting hung up on details.
 A use case represents a functional requirement of the system as a whole.
 A use case carries out some tangible amount of work. From the perspective of a
given actor, a use case does some thing that’s of value to an actor, such as
calculate a result, generate a new object or change the state of another object.
 Use cases represent an external view of the system.
Use-cases identified for our system are:
1. Use-case name: Log-In:

This use case provides the administrator to login in to the system.
19
Log-In
2. Use-case name: Request weather
Request Weather
This use case provides inforamtion about previous and present weather conditions
that is intiated by the visitor.
3.Use-case name: Enter Weather Information:

In use case the administrator inserts , updates,deletes information about
the Enter Weather
weather Information
conditions. Enter Weather Information
Enter Weather Information
4. Use-case name: Logout:

This usecase allows the administrator to logout from the weather
report system.
Logout
6. BUILDING REQUIREMNTS MODEL THROUGH USE-CASE

DIAGRAM
20
Use-case diagrams graphically represent system behavior (use cases). These

diagrams present a high level view of how the system is used as viewed from an
outsider’s (actor’s) perspective. A use-case diagram may contain all or some of the use
cases of a system.
A use-case diagram can contain:
• Actors ("things" outside the system)
• Use cases (system boundaries identifying what the system should do)
• Interactions or relationships between actors and use cases in the system including
the associations, dependencies, and generalizations.
Use-case diagrams can be used during analysis to capture the system
requirements and to understand how the system should work. During the design phase,
you can use use-case diagrams to specify the behavior of the system as implemented.
RELATIONS:
Association Relationship:
An association provides a pathway for communication. The
communication can be between use cases, actors, classes or interfaces. Associations are
the most general of all relationships and consequentially the most semantically weak. If
two objects are usually considered independently, the relationship is an association
By default, the association tool on the toolbox is uni-directional and drawn on a
diagram with a single arrow at one end of the association. The end with the arrow
indicates who or what is receiving the communication.
Bi-directional association:
If you prefer, you can also customize the toolbox to include the bi-
directional tool to the use-case toolbox.
In An ASSOCIATION Relationship, we can provide Stereotype COMMUNICATE also
as shown below
21
<<communicate>>
LOGIN
USER
Dependency Relationship:
A dependency is a relationship between two model elements in which a change to one

model element will affect the other model element. Use a dependency relationship to
connect model elements with the same level of meaning. Typically, on class diagrams, a
dependency relationship indicates that the operations of the client invoke operations of
the supplier.
We can provide here

1. Include Relationship.
2. Extend Relationship
• There are two types of relationships that may exist between use cases: include
relationship and extend relationship.
• Multiple use cases may share pieces of the same functionality. This functionality
is placed in a separate use case rather than documenting it in every use case that
needs it
• Include relationships are created between the new use case and any other use case
that "uses" its functionality.
An include relationship is a stereotyped relationship that connects a base use case
to an inclusion use case. An include relationship specifies how behavior in the inclusion
use case is used by the base use case.
<<include>>
BASE USE-CASE INCLUSION USE-CASE

22
Extended Relationship:
An extend relationship is a stereotyped relationship that specifies how the

functionality of one use case can be inserted into the functionality of another use case.
Extend relationships between use cases are modeled as dependencies by using the Extend
stereotype.
An extend relationship is used to show

• Optional behavior
• Behavior that is run only under certain conditions such as triggering an alarm
• Several different flows that may be run based on actor selection
• An extend relationship is drawn as a dependency relationship that points from the
extension to the base use case
The extend relationship sample demonstrates how you can use an extend relationship to
connect use cases. The sample illustrates two important aspects of extend relationships:
· An extend relationship shows optional functionality or system behavior.
· A base use case does not need to acknowledge any specific extended use cases
Finally we can conclude
«extend» is used when you wish to show that a use case provides additional functionality
that may be required in another use case.
«include» applies when there is a sequence of behavior that is used frequently in a
number of use cases, and you want to avoid copying the same description of it into each
use case in which it is used.
23
The usecase diagram

for weather report
system
REQUEST
weather
LEVEL 0:
ENTER
WEATHER
information
Administrator
24
VISITOR
Level 1:
25
<<include>>
<<include>> <<include>>
<<include>> states
previous
<<include>>
<<include>> countries
<<include>>
request weather detail
present
<<include>>
usename
login <<include>>
password administrator
visitor
logout
<<include>>
state
<<include>>
enter weather information
<<include>> <<include>> country
date
details
26
The entire use case for weather report system
<<include>>
<<extend>>
<<include>> <<include>>
<<extend>>
<<include>> states
previous
<<include>>
<<include>> <<extend>>
countries display weather report
<<include>>
request weather detail
present
<<include>>
usename
login <<include>>
password administrator
visitor
logout
<<include>>
state
<<include>>
enter weather information
<<include>> <<include>> country
date
details
7. FLOW OF EVENTS
27
A flow of events is a sequence of transactions (or events) performed by the

system. They typically contain very detailed information. Flow of events document is
typically created in the elaboration phase.
Each use case is documented with flow of events
 a description of events needed to accomplish required behavior
 written in terms of what the system should do, NOT how it should do it
 written in the domain language, not in terms of the implementation
A flow of events should include:
 When and how the use case starts and ends
 What interaction the use case has with the actors
 What data is needed by the use case
 The normal sequence of events for the use case
 The description of any alternate or exceptional flows
The flow of events for a use case is contained in a document called the Use Case
Specification. Each project should use a standard template for the creation of the Use
Case Specification. Includes the following
1. Use case name, Brief Description
2. Flow of Events -
1. Basic flow.
2. Alternative flow.
3. Special requirements.
4. Pre conditions.
5. Post conditions.
6. Extension points.
28
Use case specification for the login Use Case

1.0 Use Case Name: Login
1.1 Brief Description
This use case is intiated by administrator to enter the weather information into the
weather report system.
2.0 Flow of Events
2.1 Basic Flow
1. Administrator opens the weather report system.
2. System displays the login page.
3. Administrator enter username and login.
4. Administrator submits the information.
5. [if login success] Admin enters the system
2.2 Alternate Flows

2.2.1 Invalid Password
An invalid password is entered. The user can re-enter a password or terminate the
use case.
3.0 Special Requirements
There are no special requirements for this use case.
4.0 Pre conditions
There are no pre conditions.
5.0 Post conditions
There are no post conditions.
6.0 Extension Points
29
Use case Specification for the Request Weather Use Case
1.0 Use Case Name: Request Weather

It provides information about previous and present weather conditions and is intiated
by the visitor.
2.0 Flow of Events
2.1 Basic Flow
1. visitor opens the weather report system
2. system displays the home page.
3. visitor selects details of either present ot previous weather information.
4. system provides information according to the user request.
2.2 Alternate Flows
2.2.1 If account expired simply exit from the system.
There are no special requirements for this use case.
4.0 Pre conditions
5.0 Post conditions
None.
Use case specification for the Enter Weather Information Use Case
1.0 Use Case Name: Enter Weather Information
Administrator inserts ot edits information abou the weather condtions.
2.0 Flow of Events
2.1 Basic Flow
1.Administrator clicks on “Enter Weather information button
2.Administrator inserts or edits the details about country,state,date,details.
30
There are no special requirements for this usecase.

4.0 Preconditions
5.0 Post conditions
None.
Use case specification for the logout Use Case
1.0 Use Case Name: Logout
This usecase allows the adminitrator to logout from the weather report system.
2.0 Flow of Events
2.1 Basic Flow
1.Administrator clicks on the logout button
2.The weather system takes him back to the main oage of weather report.
There are no special requirements for this usecase.
4.0 Preconditions
5.0 Post conditions
6.0 Extension Points:None.
31
8. Sample PROTOTYPES FOR APPLICATION

2.
1.
Do you want to get Weather report

Do report
weather
Login weather report
Admin
Click Logout
hrerhere
3. 4.
Enter your option

Enter username,
password
 Previous
Username:  present
Pass:
ok cancel
1.
5. 6.
Previous Present
Enter the temp
Enter the temp
Report temp
7.
Report past:
Information
8.
Cname:
Report
about the past Mintemp:
and present
information of Maxtemp:
weather.
Rainfall:
done
ok cancel
32
9. ACTIVITY DIAGRAM
An Activity diagram is a variation of a special case of a state machine, in which

the states are activities representing the performance of operations and the transitions are
triggered by the completion of the operations.
The purpose of Activity diagram is to provide a view of flows and what is going
on inside a use case or among several classes.
You can also use activity diagrams to model code-specific information such as a
class operation.
Activity diagrams are very similar to a flowchart because you can model a
workflow from activity to activity.
An activity diagram is basically a special case of a state machine in which most
of the states are activities and most of the transitions are implicitly triggered by
completion of the actions in the source activities.
• ACTIVITY DIAGRAMS represent the dynamics of the system.
• They are flow charts that are used to show the workflow of a system; that is, they
show the flow of control from activity to activity in the system, what activities
can be done in parallel, and any alternate paths through the flow.
• At this point in the life cycle, activity diagrams may be created to represent the
flow across use cases or they may be created to represent the flow within a
particular use case.
• Later in the life cycle, activity diagrams may be created to show the workflow for
an operation.
Activity diagrams can model many different types of workflows. For example, a
company could use activity diagrams to model the flow for an approval of orders or to
model the paper trail of invoices. An accounting firm could use activity diagrams to
model any number of financial transactions. A software company could use activity
diagrams to model a software development process.
The following tools are used on the activity diagram toolbox to model activity
diagrams:
33
ACTIVITIES:
An activity represents the performance of task or duty in a workflow. It
may also represent the execution of a statement in a procedure. An activity is similar
to a state, but expresses the intent that there is no significant waiting (for events) in an
activity.
The activity icon appears as a rectangle with rounded ends with a name and
a compartment for actions.
NewActivity
TRANSITIONS:
Transitions connect activities with other model elements and object flows
connect activities with objects. Transitions are used to show the passing of the flow
of control from activity to activity. They are typically triggered by the completion of
the behavior in the originating activity.
A state transition indicates that an object in the source state will perform
certain specified actions and enter the destination state when a specified event occurs
or when certain conditions are satisfied. A state transition is a relationship between
two states, two activities, or between an activity and a state.
NAMING:
The name of a state should be unique to its enclosing class, or if nested,
within the state. All state icons with the same name in a given diagram represent the
same state.
Actions:
Actions on states can occur at one of four times:
• On entry
• On exit
• Do
• On event
34
DECISIONS:
When modeling the workflow of a system it is often necessary to
show where the flow of control branches based on a decision point. The transitions from
a decision point contain a guard condition, which is used to determine which path from
the decision point is taken. Decisions along with their guard conditions allow you to
show alternate paths through a work flow.
A decision represents a specific location on an activity diagram or state chart
diagram where the workflow may branch based upon guard conditions. There may be
more than two outgoing transitions with different guard conditions, but for the most part,
a decision will have only two outgoing transitions determined by a Boolean expression.
Decision Point
END STATE:
An end state represents a final or terminal state on an activity diagram or state
chart diagram. Place an end state when you want to explicitly show the end of a
workflow on an activity diagram or the end of a state chart diagram. Transitions can only
occur into an end state; however, there can be any number of end states per context.
End state
START STATE:
A start state, (also called an “initial state”) explicitly shows the beginning of a
workflow on an activity diagram or the beginning of the execution of a state machine on
a state chart diagram.
Start state
35
SWIM LANES:
Swim lanes may be used to partition an activity diagram. This typically is done to
show what person or organization is responsible for the activities contained in the swim
lane.
Swim lanes are helpful when modeling a business workflow because they can
represent organizational units or roles within a business model. Swim lanes are very
similar to an object because they provide a way to tell who is performing a certain role.
Swim lanes only appear on activity diagrams.
When a swim lane is dragged onto an activity diagram, it becomes a swim lane
view. Swim lanes appear as small icons in the browser while a swim lane views appear
between the thin, vertical lines with a header that can be renamed and relocated.
SYNCHRONIZATION BARS:
In a workflow there are typically some activities that may be done in parallel. A
synchronization bar allows you to specify what activities may be done concurrently.
Synchronization bars are also used to show joins in the workflow; that is, what
activities must complete before processing may continue.
Means, a synchronization bar may have many incoming transitions and one
outgoing transition, or one incoming transition and many outgoing transitions.
Horizontal synchronization Vertical synchronization

CREATING GUARDED TRANSITIONS IN RATIONAL ROSE:
1. Click to select the State Transition icon from the toolbar.
2. Click on the decision and drag the transition to the successor activity.
3. Double-click on the transition arrow to make the Specification visible.
4. Select the Detail tab.
5. Enter the guard condition in the Guard Condition field.
6. Click the OK button to close the Specification.
36
Modeling a workflow in an activity diagram can be done several ways; however, the
following steps present just one logical process:
1. Identify a workflow objective. Ask, "What needs to take place or happen by the end of
the workflow? What needs to be accomplished?" For example, if your activity diagram
models the workflow of ordering a book from an online bookstore, the goal of the entire
workflow could be getting the book to the customer.
2 Decide the pre and post-conditions of the workflow through a start state and an end
state. In most cases, activity diagrams have a flowchart structure so start and end states
are used to designate the beginning and ending of the workflow. State and end states
clarify the perimeter of the workflow.
3. Define and recognize all activities and states that must take place to meet your
objective. Place and name them on the activity diagram in a logical order.
4. Define and diagram any objects that are created or modified within your activity
diagram. Connect the objects and activities with object flows.
5. Decide who or what is responsible for performing the activities and states through
swim lanes. Name each swim lane and place the appropriate activities and states within
each swim lane.
6. Connect all elements on the diagram with transitions. Begin with the "main"
workflow.
7. Place decisions on the diagram where the workflow may split into an alternate flow.
For example, based on a Boolean expression, the workflow could branch to a different
workflow.
8. Evaluate your diagram and see if you have any concurrent workflows. If so, use
synchronizations to represent forking and joining.
9. Set all actions, triggers and guard conditions in the specifications of each model
element.
37
The activity diagram for the overall system is
a d m in is tr a to r user
user
a d m in is tr a to r
lo g i n
u s e r a n d p a s s w rd
n o t v a li d p re s e n t p re v io u s cancel
v a li d
d e le te
d e t a i ls c o u n t r y s t a t e d a te s ta te c o u n tr y d e ta ils d a te
th a n k y o u
lo g o u t
38
Logical View
10. IDENTIFICATION OF ANALYSIS CLASSES

The class diagram is fundamental to object-oriented analysis. Through successive
iterations, it provides both a high level basis for systems architecture, and a low-level
basis for the allocation of data and behavior to individual classes and object instances,
and ultimately for the design of the program code that implements the system. So, it is
important to identify classes correctly. However, given the iterative nature of the object-
oriented approach, it is not essential to get this right on the first attempt itself.
APPROACHES FOR IDENTIFYING CLASSES:

We have four alternative approaches for identifying classes:
1. The noun phrase approach;
2. The common class patterns approach;
3. The use- case driven TO sequence/collaboration modeling approach;
4. Class Responsibility collaboration cards (CRC) approach.
The first two approaches have been included to increase analysts
understanding of the subject; the unified approach uses the use-case driven approach for
identifying classes and understanding the behavior of objects. However, these can be
combined to identify classes for a given problem.
1. NOUN PHRASE APPROACH.

In this method, analysts read through the requirements or use cases looking for
noun phrases. Nouns in the textual description are considered to be classes and verbs to
be methods of the classes All plurals are changed to singular, the nouns are listed, and the
list divided into three categories relevant classes, fuzzy classes (the "fuzzy area," classes
we are not sure about), and irrelevant classes as shown below.
39
Using the noun phrase strategy, candidate classes can be divided into three
categories: Relevant classes, Fuzzy Area or Fuzzy classes (those classes that we are not
sure about), and irrelevant classes.
It is safe to scrap the irrelevant classes, which either have no purpose or will be
unnecessary. Candidate classes then are selected from the other two categories. Here
identifying classes and developing a UML class diagram just like other activities is an
iterative process. Depending on whether such object modeling is for the analysis or
design phase of development, some classes may need to be added or removed from the
model .Analyst must be able to formulate a statement of purpose for each candidate class;
if not, simply eliminate it.
1 Identifying Tentative Classes:
The following are guidelines for selecting classes in an application:
• Look for nouns and noun phrases in the use cases.
• Some classes are implicit or taken from general knowledge.
• All classes must make sense in the application domain; avoid computer
implementation classes refer them to the design stage.
• Carefully choose and define class names.
Identifying classes is an incremental and iterative process. This incremental and
iterative nature is evident in the development of such diverse software technologies as
graphical user interfaces, database standards, and even fourth-generation languages.
2 Selecting Classes from the Relevant and Fuzzy Categories :
The following guidelines help in selecting candidate classes from the
relevant and fuzzy categories of classes in the problem domain.
40
a) Redundant classes. Do not keep two classes that express the same
information. If more than one word is being used to describe the same idea, select the one
that is the most meaningful in the context of the system. This is part of building a
common vocabulary for the system as a whole. Choose your vocabulary carefully; use the
word that is being used by the user of the system.
b) Adjectives classes. "Be wary of the use of adjectives. Adjectives can be used
in many ways. An adjective can suggest a different kind of object, different use of the
same object, or it could be utterly irrelevant. Does the object represented by the noun
behave differently when the adjective is applied to it? If the use of the adjective signals
that the behavior of the object is different, then make a new class".
For example : Single account holders behave differently than Joint
account holders, so the two should be classified as different classes.
c) Attribute classes: Tentative objects that are used only as values should be
defined or restated as attributes and not as a class. For example, Client Status and Details
of Client are not classes but attributes of the Client class.
d) Irrelevant classes: Each class must have a purpose and every class should be
clearly defined and necessary. You must formulate a statement of purpose for each
candidate class. If you cannot come up with a statement of purpose, simply eliminate the
candidate class.
As this is an incremental process. Some classes will be missing; others will be
eliminated or refined later. Unless you are starting with a lot of domain knowledge, you
probably are missing more classes than you will eliminate. Although some classes
ultimately may become super classes, at this stage simply identify them as individual,
specific classes. Your design will go through many stages on its way to completion, and
you will have adequate opportunity to revise it.
This refining cycles through the development process until you are
satisfied with the results. Remember that this process (of eliminating redundant classes,
classes containing adjectives, possible attributes, and irrelevant classes) is not sequential.
You can move back and forth among these steps as often analysts likes.
41
2) COMMON CLASS PATTERNS APPROACH

The second method for identifying classes is using common class patterns,
which is based on a knowledge base of the common classes. The following patterns are
used for finding the candidate class and object:
a) Concept class: A concept is a particular idea or understanding that we have
of our world. The concept class encompasses principles that are not tangible but used to
organize or keep track of business activities or communications.
Example: Performance is an example of concept class object.
b) Events class: Events classes are points in time that must be recorded.
Things happen, usually to something else at a given date and time or as a step in an
ordered sequence. Associated with things remembered are attributes (after all, the things
to remember are objects) such as who, what, when, where, how, or why.
Example: Landing, interrupt, request, and order are possible events.
c) Organization class: An organization class is a collection of people, resources,
facilities, or groups to which the users belong; their capabilities have a defined mission,
whose existence is largely independent of the individuals.
Example: An accounting department might be considered a potential class.
d) People class (also known as person, roles, and roles played class):
The people class represents the different roles users play in interacting
with the application.
Example: Employee, client, teacher, and manager are examples of people.
e) Places class: Places are physical locations that the system must keep
information about.
Example: Buildings, stores, sites, and offices are examples of places.
42
3) USE-CASE DRIVEN APPROACH:

IDENTIFYING CLASSES AND THEIR BEHAVIORS THROUGH
SEQUENCE/COLLABORATION MODELING
One of the first steps in creating a class diagram is to derive from a use
case, via a collaboration (or collaboration diagram), those classes that participate in
realizing the use case. Through further analysis, a class diagram is developed for each use
case and the various use case class diagrams are then usually assembled into a larger
analysis class diagram. This can be drawn first for a single subsystem or increment, but
class diagrams can be drawn at any scale that is appropriate, from a single use case
instance to a large, complex system.
Identifying the objects involved in collaboration can be difficult at first,
and takes some practice before the analyst can feel really comfortable with the process.
Here collaboration (i.e. the set of classes that it comprises) can be identified directly for a
use case, and that, once the classes are known, the next step is to consider the interaction
among the classes and so build a collaboration diagram.
From collaboration diagram to class diagram

The next step in the development of a requirements model is usually to produce a
class diagram that corresponds to each of the collaboration diagrams. The class diagram
that corresponds to the use case E-Pay is shown below.
Collaboration diagrams are obtained by result of reasonably careful analysis, the
transition is not usually too difficult.
The similarities & differences B/W Collaboration and class diagrams are:
First, consider the similarities:
Both show class or object symbols joined by connecting lines. In general, a class
diagram has more or less the same structure as the corresponding collaboration diagram.
Next, the differences are:
1. The difference is that an actor is almost always shown on a collaboration diagram, but
not usually shown on a class diagram. This is because the collaboration diagram
represents a particular interaction and the actor is an important part of this interaction.
However, a class diagram shows the more enduring structure of associations among the
43
classes, and frequently supports a number of different interactions that may represent
several different use cases.
2. A collaboration diagram usually contains only object instances, while a class diagram
usually contains only classes.
3. The connections between the object symbols on a collaboration diagram symbolize
links between objects, while on a class diagram the corresponding connections stand for
associations between classes.
4. A collaboration diagram shows the dynamic interaction of a group of objects and thus
every link needed for message passing is shown. The labeled arrows alongside the links
represent messages between objects. On a class diagram, the associations themselves are
usually labeled, but messages are not shown.
5. Finally, any of the three stereotype symbols can be used on either diagram; there are
also differences in this notation.
When the rectangular box variant of the notation is used in a collaboration
diagram it represents object instances rather than classes, is normally undivided and
contains only the class name .On a class diagram, the symbol is usually divided into three
compartments that contain in turn the class name, its attributes and its operations.
4) Class Responsibility collaboration Cards (CRC Cards)

At the starting, for the identification of classes we need to concentrate completely
on uses cases. A further examination of the use cases also helps in identifying operations
and the messages that classes need to exchange. However, it is easy to think first in terms
of the overall responsibilities of a class rather than its individual operations.
A responsibility is a high level description of something a class can do. It reflects
the knowledge or information that is available to that class, either stored within its own
attributes or requested via collaboration with other classes, and also the services that it
can offer to other objects. A responsibility may correspond to one or more operations. It
is difficult to determine the appropriate responsibilities for each class as there may be
many alternatives that all appear to be equally justified.
44
11. IDENTIFICATION OF RESPONSIBILITIES OF CLASSES
Class Responsibility Collaboration (CRC) cards provide an effective technique for

exploring the possible ways of allocating responsibilities to classes and the collaborations
that are necessary to fulfill the responsibilities.
CRC cards can be used at several different stages of a project for different
purposes.
1. They can be used early in a project to help the production of an initial class diagram .
2. To develop a shared understanding of user requirements among the members of the
team.
3. CRCs are helpful in modeling object interaction.
The format of a typical CRC card is shown below
Class Name:
Responsibilities Collaborations
Responsibilities of a Collaborations with other
class are listed in this classes are listed here, together
section with a brief description of the
purpose of the collaboration
CRC cards are an aid to a group role-playing activity. Index cards are used in preference
to pieces of paper due to their robustness and to the limitations that their size (approx.
15cm x 8cm) imposes on the number of responsibilities and collaborations that can be
effectively allocated to each class.
A class name is entered at the top of each card and responsibilities and collaborations are
listed underneath as they become apparent. For the sake of clarity, each collaboration is
normally listed next to the corresponding responsibility.
From a UML perspective, use of CRC cards is in analyzing the object interaction
that is triggered by a particular use case scenario. The process of using CRC cards is
usually structured as follows.
45
1. Conduct a session to identify which objects are involved in the use case.
2. Allocate each object to a team member who will play the role of that object.
3. Act out the use case.
This involves a series of negotiations among the objects to explore how
responsibility can be allocated and to identify how the objects can collaborate with each
other.
4. Identify and record any missing or redundant objects.
Before beginning a CRC session it is important that all team members are briefed on the
organization of the session and a CRC session should be preceded by a separate exercise
that identifies all the classes for that part of the application to be analyzed.
The team members to whom these classes are allocated can then prepare for the
role playing exercise by considering in advance a first-cut allocation of responsibilities
and identification of collaborations. Here, it is important to ensure that the environment
in which the sessions take place is free from interruptions and free for the flow of ideas
among team members.
During a CRC card session, there must be an explicit strategy that helps to
achieve an appropriate distribution of responsibilities among the classes. One simple but
effective approach is to apply the rule that each object should be as lazy as possible,
refusing to take on any additional responsibility unless instructed to do so by its fellow
objects.
During a session conducted according to this rule, each role player identifies the object
that they feel is the most appropriate to take on each responsibility, and attempts to
persuade that object to accept the responsibility. For each responsibility that must be
allocated, one object is eventually persuaded by the weight of rational argument to accept
it. This process can help to highlight missing objects that are not explicitly referred to by
the use case description. When responsibilities can be allocated in several different ways
it is useful to role-play each allocation separately to determine which is the most
appropriate. The aim normally is to minimize the number of messages that must be
passed and their complexity, while also producing class definitions that are cohesive and
well focused.
46
The following are the responsibilities of each class in our application weather report
system
Login:
This use case is intiated by administrator to enter the weather information into the
1. Administrator:
This class controls the total maintenance of weather report system and controls
all the operations like updating ,inserting ,deleting in the system.
2. User:
This class is used to view the weather report in the weather report system.
3. Weather report maintainance:

The main responsibility of this class is to maintain the details of the weather
report system like details,state,country,date of previous and present situations.
4. Weather Reports:
This class maintains reports of weather conditons of state,country,details,date as
requested by user .
47
The Classes, Responsibilities, and Collaborators process consists of three steps:
1. Identify classes’ responsibilities (and identify classes)

2. Assign responsibilities
3. Identify collaborators
These are main responsibilities of classes in our application.
Class Name Reponsibilities

Administrator Controls total maintenance of weather
report system .
User Views the weather information in the

Weather report maintainance Maintainss the details of weathe report

system.
Weather Reports
Maintains reports of weather conditons
of state,country,details,date as requested
by user .
48
12.USE-CASE REALIZATIONS
Use case realization is nothing but an instance of a use case which involves the
identification of a possible set of classes, together with an understanding of how those
classes might interact to deliver the functionality of the use case. The set of classes is
known as collaboration.
In the UML, use case realizations are drawn as dashed ovals and relation ship symbols
are as shown below.
Realization relationship
symbol for use case

----------------
realization
A use case realization is a graphic sequence of events, also referred as a scenario or an

instance of a use case. These realizations or scenarios are represented using either a
sequence or collaboration diagrams.
Use case Realization can be provided using
Sequence diagrams,
Collaboration diagrams and
Class diagrams.
These diagrams can also be given by considering any scenario from the system or sub-
system
49
The following are the use case realizations in our project:

50
13. SEQUENCE DIAGRAM

A sequence diagram is a graphical view of a scenario that shows object
interaction in a time based sequence----what happens first, what happens next….
Sequence diagrams establish the roles of objects and help provide essential
information to determine class responsibilities and interfaces.
A sequence diagram has two dimensions: the vertical dimension represents time;
the horizontal dimension represents different objects. The vertical line is called the
object’s lifeline. The lifeline represents the object’s existence during the interaction.
Steps:
1. An object is shown as a box at the top of a dashed vertical line. Object names can be
specific (e.g., Algebra 101, Section 1) or they can be general (e.g., a course offering).
Often, an anonymous object (class name may be used to represent any object in the
class.)
2. Each message is represented by an Arrow between the lifelines of two objects. The
order in which these messages occur is shown top to bottom on the page. Each message is
labeled with the message name.
Time normally proceeds down the page. However, a sequence diagram may be drawn
with a horizontal time axis if required, and in this case, time proceeds from left to right
across the page. Each object is represented by a vertical dashed line, called a lifeline, with
an object symbol at the top. A message is shown by a solid horizontal arrow from one
lifeline to another and is labeled with the message name. Each message name may
optionally be preceded by a sequence number that represents the sequence in which the
messages are sent, but this is not usually necessary on a sequence diagram since the
message sequence is already conveyed by their relative positions along time axis.
Sequence diagrams and collaboration diagrams are together called the interaction
diagrams. These are two of the five diagrams used in UML to model the dynamic aspects
of systems. An interaction diagram shows the interaction consisting of a set of objects
and their relationships including the messages that may be dispatched among them.
Interaction diagrams are models that describe how groups of objects collaborate in some
behavior. Interaction diagrams commonly contain – objects, links, and messages.
51
Purpose of sequence diagrams:

• A sequence diagram is an interaction diagram that emphasizes the time ordering
of messages.
• The sequence diagram is used primarily to show the interactions between objects
in the sequential order that those interactions occur.
• One of the primary uses of sequence diagrams is in the transition from
requirements expressed as use cases to the next and more formal level of
refinement. Use cases are often refined into one or more sequence diagrams.
• In addition to their use in designing new systems, sequence diagrams can be used
to document how objects in an existing (call it “legacy”) system currently interact.
This documentation is very useful when transitioning a system to another person
or organization.
• The main purpose of a sequence diagram is to define event sequences that result
in some desired outcome. The focus is less on messages themselves and more on
the order in which messages occur; nevertheless, most sequence diagrams will
communicate what messages are sent between a system’s objects as well as the
order in which they occur.
• The diagram conveys this information along the horizontal and vertical
dimensions: the vertical dimension shows, top down, the time sequence of
messages/calls as they occur, and the horizontal dimension shows, left to right,
the object instances that the messages are sent.
ELEMENTS OF SEQUENCE DIAGRAMS:
There are mainly five elements in sequence diagrams. Three of them are common to the
two interaction diagrams and two are for sequential diagrams. They are-
• Objects
• Links
• Messages
• Focus of control
• Object life line
52
An object is a concrete manifestation of a class to which a set of operations can be

applied and which has a state that stores the effects of the operations. Objects are
instances of classes.
A link is a semantic connection among objects. In general, a link is an instance of an

association. Whenever a class has an association to another class, there may be a link
between the instances of the two classes; whenever there is a link between two objects,
one object can send a message to the other object.
A message is the specification of a communication among objects that conveys

information with expectation that activity will ensure. The receipt of message instance
may be considered an instance of an event. When a message is passed, the action that
results is an executable statement. An action may result in a change in state.
The focus of control is a tall, think rectangle that shows the period of time during which
an object is performing an action, either directly or through a subordinate procedure.
An object lifeline is a vertical dashed line that represents the existence of an object over
a period of time. Most objects that appear in an interaction diagram will be in existence
of an object over a period of time. Most objects that appear in an interaction diagram will
be in existence for the duration of the interaction.
Message to self: A message to self is a tool that sends a message from one object back to
the same object. It does not involve other objects because the message returns to the same
object. The sender of a message is the same as the receiver.
53
Sequence diagram for our system is as follows:
: :weather report : :weatherReport : :Database

: administrator
1: start interface
2: insert info
3: insert
4: enter info about country,state,details

5: info added
6: values updated
7: delete info
8: delete
9: enter info to be deleted

10: deleted
11: info deleted

54
14. COLLABORATION DIAGRAM
A collaboration diagram is an alternate way to show a scenario. This type of diagram

shows object interactions organized around the objects and their links to each other. A
collaboration diagram contains:
 Objects drawn as rectangles
 Links between objects shown as lines connecting the linked objects
 Messages shown as text and an arrow that points from the client to the supplier
Message labels in collaboration diagrams:

Messages on a collaboration diagram are represented by a set of symbols that are
the same as those used in a sequence diagram, but with some additional elements to show
sequencing and recurrence as these cannot be inferred from the structure of the diagram.
Each message label includes the message signature and also a sequence number that
reflects call nesting, iteration, branching, concurrency and synchronization within the
interaction.
The formal message label syntax is as follows:
[Predecessor] [guard-condition] sequence-expression [return-value ':='] message-name' ('
[argument-list] ')'
A predecessor is a list of sequence numbers of the messages that must occur
before the current message can be enabled. This permits the detailed specification of
branching pathways. The message with the immediately preceding sequence number is
assumed to be the predecessor by default, so if an interaction has no alternative pathways
the predecessor list may be omitted without any ambiguity. The syntax for a predecessor
is as follows:
Sequence-number { ',' sequence-number} 'I'
The 'I' at the end of this expression indicates the end of the list and is only
included when an explicit predecessor is shown.
Guard conditions are written in Object Constraint Language (OCL), and are only
shown where the enabling of a message is subject to the defined condition. A guard
condition may be used to represent the synchronization of different threads of control.
55
A sequence-expression is a list of integers separated by dots ('.') optionally

followed by a name (a single letter), optionally followed by a recurrence term and
terminated by a colon. A sequence-expression has the following syntax:
Integer {‘.' integer} [name] [recurrence] ':'
In this expression integer represents the sequential order of the message. This may be
nested within a loop or a branch construct.
The name of a sequence-expression is used to differentiate two concurrent
messages since these are given the same sequence number.
Recurrence reflects either iterative or conditional execution and its syntax is as
follows:
Branching: ‘[‘condition-clause‘ ],
Iteration: ‘* ‘‘[‘iteration-clause ‘ ]’
A collaboration diagram emphasizes the organization of the objects that
participate in an interaction. Collaboration diagrams are a static construct to show objects
and messages involved in accomplishing a purpose or a set of purposes.
Purpose of collaboration diagrams:

• A collaboration diagram emphasizes the organization of the objects that
participate in an interaction.
• Collaboration diagrams do a better job of visualizing complex iteration and
branching and of visualizing multiple flows of control than do sequence diagrams.
• Collaboration diagrams model the flow of control by organization. Modeling a
flow control by organization emphasizes the structural relation ships among the
instances in the interaction, along which messages may be passed.
Elements of Collaboration Diagrams:

There are mainly five elements in collaboration diagrams. Three of them are common to
the two interaction diagrams and two are for collaboration diagrams. They are:
• Objects
• Links
56
• Messages
• Path
• Sequence number
An object is a concrete manifestation of a class to which a set of operations can be
applied and which has a state that stores the effects of the operations. Objects are
instances of classes.
A link is a semantic connection among objects. In general, a link is an instance of an

association. Whenever a class has an association to another class, there may be a link
between the instances of the two classes; whenever there is a link between two objects,
one object can send a message to the other object.
A message is the specification of a communication among objects that conveys

information with the expectation that activity will ensure. The receipt of message
instance may be considered an instance of an event. When a message is passed, the action
that results is an executable statement. An action may result in a change in state.
A path is used to indicate how one object is linked to another. A path stereotype is
attached to the far end of the link. The link of the path should be rendered explicitly.
A sequence number is used to indicate the time order of a message. The message is
prefixed with a number which increases monotonically for each new message in the flow
of control.
Two types of Numbering Sequences are:
1. Flat Sequence
2. Decimal Sequence
Difference between sequence and collaboration diagrams
 Sequence diagrams are closely related to collaboration diagrams and both are
alternate representations of an interaction.
57
 Sequence diagrams show time-based object interaction while collaboration

diagrams show how objects associate with each other.
 A sequence diagram is a graphical view of a scenario that shows object
interaction in a time based sequence
 A collaboration diagram shows object interactions organized around the objects
and their links to each other.
 The Create Collaboration Diagram Command creates a collaboration diagram
from information contained in the sequence diagram. The Create Sequence
Diagram Command creates a sequence diagram from information contained in the
interaction’s collaboration diagram.
Collaboration diagrams for our system are as follows:
1: start interface
: administrator : :weather report
3: insert
4: enter info about country,state,details 8: delete
9: enter info to be deleted
2: insert info
7: delete info
6: values updated
11: info deleted
: :weatherReport 5: info added

10: deleted
: :Database
This is the collaboration diagrams in our project Weather Report System

58
15. IDENTIFICATION OF METHODS AND ATTRIBUTES OF

CLASSES
Attributes
Attributes are part of the essential description of a class. They belong to the class, unlike
objects, which instantiate the class. Attributes are the common structure of what a
member of the class can 'know'. Each object will have its own, possibly unique, value for
each attribute.
Guidelines for identifying attributes of classes are as follows:
 Attributes usually correspond to nouns followed by prepositional phrases.
Attributes also may correspond to adjectives or adverbs.
 Keep the class simple; state only enough attributes to define the object state.
 Attributes are less likely to be fully described in the problem statement.
 Omit derived attributes.
 Do not carry discovery attributes to excess.
Some questions are there which help in identifying the responsibilities of classes and
deciding what data elements to keep track of:
• What information about an object should we keep track of?
• What services must a class provide?
Answering the first question helps us to identify the attributes of a class. Answering the
second question helps us to identify class methods.
The attributes identified in our system are:
• Attributes for Administrator : username,password.

• Attributes for Weather Report Maintainance : details,country,state,date
• Attributes for User : none.
• Attributes for Weather Reports: Reports
59
The responsibilities identified in our system are:
• Methods for Administrator:username,password,login,startinterface

• Methods for Weather Report Maintainance :addinfo,deleteinfo,update
• Methods for User: view reports
• Methods for Weather Reports: none.
16 . IDENTIFICATION OF RELATIONSHIPS AMONG CLASSES
NEED FOR RELATIONSHIPS AMONG CLASSES:

All systems are made up of many classes and objects. System behavior is
achieved through the collaborations of the objects in the system.
For example, a passenger can perform reservation operation by submitting form to
reservation clerk. This is often referred to as an object sending a message to another
object. Relationships provide the medium or tool for object interaction.
Two types of relationships in CLASS diagram are:
1. Associations Relationship
2. Aggregations Relationship
1. ASSOCIATION RELATIONSHIPS:
An association is a bidirectional semantic connection between classes. It is not a
data flow as defined in structured analysis and design data may flow in either direction
across the association. An association between classes means that there is a link between
objects in the associated classes.
2. AGGREGATION RELATIONSHIPS:
An aggregation relationship is a specialized form of association in which a whole
is related to its part(s). Aggregation is known as a "part-of" or containment relationship.
60
The UML notation for an aggregation relationship is an association with a diamond next
to the class denoting the aggregate (whole).
3. SUPER-SUB STRUCTURE (GENERALIZATION HIERARCHY):

These allow objects to be build from other objects. The super-sub class hierarchy
is a relationship between classes, where one class is the parent class of another class.
The following are the different relationships exits in our applications:
 Association between Administrator and the weather Report maintainance:

Weather report
Administrator maintainence
username details
password state
country
username() date
password()
login() addInfo()
start Interface() deleteinfo()
update()
17. UML CLASS DIAGRAM

• Class diagrams are created to provide a picture or view of some or all of the
classes in the model.
• The main class diagram in the logical view of the model is typically a picture of
the packages in the' system. Each package also has its own main class diagram,
which typically displays the "public" classes of the package.
A class diagram is a picture for describing generic descriptions of possible

systems. Class diagrams and collaboration diagrams are alternate representations of
object models.
61
Class diagrams contain icons representing classes, packages, interfaces, and their
relationships. You can create one or more class diagrams to depict the classes at the top
level of the current model; such class diagrams are themselves contained by the top level
of the current model.
OBJECT:
• AN OBJECT IS a representation of an entity, either real-world or conceptual.
• An object is a concept, abstraction, or thing with well defined boundaries and
meaning for an application.
• Each object in a system has three characteristics: state, behavior, and identity.
STATE: The STATE Of an object is one of the possible conditions in which it may
exist. The state of an object typically changes over time, and is defined by a set of
properties (called attributes), with the values of the properties, plus the relationships the
object may have with other objects.
Behavior:
• Behavior determines how an object responds to requests from other objects .
• Behavior is implemented by the set of operations for the object.
Identity:
• Identity means that each object is unique even if its state is identical to that of
another object.
CLASS: A CLASS IS a description of a group of objects with common properties
(attributes) common behavior (operations), common relationships to other objects, and
common semantics.
Thus, a class is a template to create objects. Each object is an instance of
some class and objects cannot be instances of more than one class.
Classes should be named using the vocabulary of the domain.
In the UML, classes are represented as compartmentalized rectangles.
The top compartment contains the name of the class.
62
The middle compartment contains the structure of the class (attributes).

The bottom compartment contains the behavior of the class (operations) as shown below.
STEREOTYPES AND CLASSES:

As like stereotypes for relationships in use case diagrams. Classes can also have
stereotypes. Here a stereotype provides the capability to create a new kind of modeling
element.
Here, we can create new kinds of classes. Some common stereotypes for a class
are entity Class, boundary Class, control class, and exception.
Notations of these stereotypes:
B o undary clas s E ntity class C ontrol class
Entity Classes
• An entity class models information and associated behavior that is generally
long lived.
• This type of class may reflect a real-world entity or it may be needed to perform
tasks internal to the system.
• They are typically independent of their surroundings; that is, they are not
sensitive to how the surroundings communicate with the system.
IDENTIFICATION:
The first step is to examine the responsibilities documented in the flow of events
for the identified use cases. Entity classes typically are classes that are needed by the
system to complete some responsibility. The nouns and noun phrases used to describe the
responsibility may be considered for identification purpose. The initial list of nouns must
be filtered because it could contain nouns that are outside the problem domain, nouns that
are just language expressions, nouns that are redundant, and nouns that are descriptions
of class structures.
Boundary Classes:
63
Boundary classes handle the communication between the system surroundings

and the inside of the system. They can provide the interface to a user or another system
(i.e., the interface to an actor). They constitute the surroundings dependent part of the
system.
Boundary classes are used to model the system interfaces.
Boundary classes are also added to facilitate communication with other systems.
During design phase, these classes are refined to take into consideration the chosen
communication protocols.
Control Classes
• Control classes model sequencing behavior specific to one or more use cases.
• Control classes coordinate the events needed to realize the behavior specified in
the use case.
• Control classes typically are application-dependent classes.
In the early stages of the Elaboration Phase, a control class is added for each
actor/use case pair. The control class is responsible for the flow of events in the use case.
In the early stages of the Elaboration Phase, a control class is added for each
actor/use case pair. The control class is responsible for the flow of events in the use case.
The following is the UML diagram for Entity Class
DataBase
The following is the UML diagram for Control Class

64
Weather Report
The following is the UML Class Diagram for our project Weather Report System:
Weather report
username details
password +1 +1...* state
country
username() date
password()
login() addInfo()
update()
+1
+1
weather reports
user +1...* +1...* Reports(details,state,country,date)
view reports()
65
18. UML STATE CHART DIAGRAM
Use cases and scenarios provide a way to describe system behavior; in the form of
interaction between objects in the system. Sometimes it is necessary to consider inside
behavior of an object.
A state chart diagram shows the states of a single object, the events or messages
that cause a transition from one state to another and the actions that result from a state
change. As in Activity diagram, state chart diagram also contains special symbols for
start state and stop state.
State chart diagram cannot be created for every class in the system, it is only for
those class objects with significant behavior.
STATE:
A state represents a condition or situation during the life of an object during
which it satisfies some condition, performs some action or waits for some event.
UML notation for STATE is
To identify the states for an object its better to concentrate on sequence diagram.
In our application the object for Account may have in the following states, initialization,
open and closed state. These states are obtained from the attribute and links defined for
the object. Each state also contains a compartment for actions.
ACTIONS:
Actions on states can occur at one of four times:
 on entry
 on exit
66
 do
 On event.
On entry: What type of action that object has to perform after entering into the state?
On exit: What type of action that object has to perform after exiting from the state?
Do: The task to be performed when object is in this state, and must to continue until it
leaves the state.
On event: An on event action is similar to a state transition label with the following
syntax:
event(args)[condition]: the Action
STATE TRANSITION:
A state transition indicates that an object in the source state will perform certain
specified actions and enter the destination state when a specified event occurs or when
certain conditions are satisfied. A state transition is a relationship between two states,
two activities, or between an activity and a state.
We can show one or more state transitions from a state as long as each transition
is unique. Transitions originating from a state cannot have the same event, unless there
are conditions on the event.
Provide a label for each state transition with the name of at least one event that
causes the state transition. You do not have to use unique labels for state transitions
because the same event can cause a transition to many different states or activities.
Transitions are labeled with the following syntax:
event (arguments) [condition] / action ^ target.sendEvent (arguments)

Only one event is allowed per transition, and one action per event.
STATE DETAILS:
Actions that accompany all state transitions into a state may be placed as an entry
action within the state. Like wise that accompany all state transitions out of a state may
67
be placed as exit actions within the state. Behavior that occurs within the state is called an
activity.
An activity starts when the state is entered and either completes or is interrupted
by an outgoing state transition. The behavior may be a simple action or it may be an
event sent to another object.
UML notation for State Details
StateName
entry/ simple action
entry/ ^class name.eventname
do/ simple action
do/ ^class name.event name
exit/ ^class name.event name
Purpose of state chart diagrams:

• We use state chart diagram when working on real-time process control
applications or systems that involve concurrent processing. It will also be used
when showing the behavior of a class over several use cases.
• State chart diagrams are used to model dynamic view of a system.
• State chart diagrams are used to emphasizing the potential states of the objects
and the transitions among those states.
• State chart diagrams are used to modeling the lifetime of an object.
• State chart diagrams are used to model the behavior of an interface. Although an
interface may not have any direct instances, a class that realizes such an interface
may. Those classes conform to behavior specified by the state machine of this
interface.
• State chart diagrams are used to focus on the changing state of a system driven by
events.
• This diagram is also for constructing executable systems through forward and
reverse engineering.
• To model reactive objects, especially instances of a class, use cases, and the
system as a whole.
68
ELEMENTS OF STATE CHART DIAGRAMS:
1. State: It is a condition or situation during the life of an object during which it satisfies
some condition, performs some activity, or waits for some event.
2. Event: It is the specification of significant occurrence that has a location in time and
space.
3. Transition: It is a relation between two states indicating that an object in the first state
will perform certain actions and enter the second state when a specified event occurs and
conditions are satisfied.
4. Action state: An action state is shorthand for a state with an entry action and at least one
outgoing transition involving the implicit event of completing the entry action.
5. Sequential sub state: A submachine state represents the invocation of a state machine
defined elsewhere. The submachine state is depicted as a normal state with the
appropriate “include” declaration within its internal transitions compartment. As an
option, the submachine state may contain one or more sub states, which represent already
created states.
6. Concurrent sub state: A concurrent state is divided into two or more sub states. It is a
state that contains other state vertices. Naturally, any sub state of a concurrent state may
also be a composite state of either type. Any state enclosed within a composite state is
called a sub state of that concurrent state.
7. Initial state: A pseudo state to establish the start of the event into an actual state.
8. Final state: The final state symbol represents the completion of the activity.
9. History state: History state is a state machine describes the dynamic aspects of an object
whose current behavior depends on its past.
10. Vertical Synchronization: This merge branch bar symbol is also known as a
“Synchronization Bar”. It merges concurrent transitions to a single target. It splits a
single transition into parallel transitions.
69
11. Horizontal Synchronization: This merge branch bar symbol is also known as a
“Synchronization Bar”. It merges concurrent transitions to a single target. It splits a
single transition into parallel transitions.
12. Guard conditions: Activity and state diagrams express a decision when conditions are
used to indicate different possible transitions that depend on Boolean conditions of
container object. UML calls those conditions as guard conditions.
13. Forks and joins: A fork construct is used to model a single flow of control that divides
into two or more separate, but simultaneous flows. A join consists of two or more flows
of control that unite into a single flow of control.
The State chart Diagram for Weather Report system:
administrator user
login
view weather
report
maintain weather
information
logout
DESIGN
70
19. DESIGNING CLASSES BY APPLYING DESIGN AXIOMS
During the design phase the classes identified in object-oriented analysis must be
Re visited with a shift in focus to their implementation. New classes or attributes and
methods must be added for implementation purpose and user interfaces.
Axiom: An axiom is a fundamental truth that always is observed to be valid and for
which is no counter example or exception.
Axiom 1: The independence axiom.
Maintain the independence of components.
Axiom 2: The information axiom.
Minimize the information content of the design.
Axiom 1 deals with relationship between system components and Axiom 2 deals
with the complexity of the design. Axiom 1 states that, during the design process, as we
go from requirement and use-case to a system component, each component must satisfy
that requirement without affecting other requirements. Axiom 2 is concerned with
simplicity.
Occam’s razor says that, “The best theory explains the known facts with a
minimum amount of complexity and maximum simplicity and straightforwardness.”
Theorem: A theorem is a proposition that may not be self-evident but can be proven
from accepted axioms.
Corollary: A corollary is a proposition that follows from an axiom or another
proposition that has been proven.
Corollary 1: Uncoupled design with less information content. Highly cohesive objects
can improve coupling because only a minimal amount of essential information need be
passed between objects.
Corollary 2: Single purpose. Each class must have a single, clearly defined purpose.
When we document, we should be able to easily describe the purpose of a class in a few
sentences.
71
Corollary 3: Large number of simple classes. Keeping the classes simple allows
reusability.
Corollary 4: Strong mapping. There must be a strong association between the physical
system (analysis’s object) and logical design (design’s object).
Corollary 5: Standardization. Promote standardization by designing interchangeable
components and reusing existing classes or components.
Corollary 6: Design with inheritance. Common behavior must be moved to super classes.
The superclass-subclass structure must make logical sense.
20. REFINING ATTRIBUTES, METHODS AND RELATIONSHIPS
Attributes
During analysis Stage we need to consider in detail the data types of the attributes
also. Common primitive data types include Boolean (true or false), Character (any
alphanumeric or special character), Integer (whole numbers) and Floating-Point (decimal
numbers). In most object-oriented languages more complex data types, such as Money,
String, Date, or Name can be constructed from the primitive data types or may be
available in standard libraries. An attribute's data type is declared in UML using the
following syntax:
name ':' type-expression '=' initial-value '{'property-string'}'
The name is the attribute name, the type-expression is its data type, the initial
value is the value the attribute is set to when the object is first created and the property-
string describes a property of the attribute, such as constant or fixed. The characters in
single quotes are literals.
Attribute declarations can also include arrays also. For example, an Employee
class might include an attribute to hold a list of qualifications that would be declared
using the syntax: Qualification [O ... 10]: String
Operations
72
Each operation also has to be specified in terms of the parameters that it passes
and returns. The syntax used for an operation is:
Operation name' ('parameter-list ') “: “return-type-expression
An operation's signature is determined by the operation's name, the number and
type of its parameters and the type of the return value if any.
Object visibility
The concept of encapsulation is one of the fundamental principles of object-
orientation. During analysis various assumptions have been made regarding the
encapsulation boundary for an object and the way that objects interact with each other.
For example, it is assumed that the attributes of an object cannot be accessed
directly by other objects but only via 'get' and 'set' operations (primary operations) that
are assumed to be available for each attribute. Moving to design involves making
decisions regarding which operations (and possibly attributes) are publicly accessible. In
other words we must define the encapsulation boundary.
The following are the different kinds of visibilities, their symbols and their
meaning.
Visibility Visibility Meaning
symbol
+ Public The feature (an operation or an attribute) is directly
accessible by an instance of any class.
- Private The feature may only be used by an instance of the class
that includes it.
# Protected The feature may be used either by instances of the class
that includes it or of a subclass or descendant of that
class.
~ Package The feature is directly accessible only by instances of a
class in the same package.
Interfaces
Generally a class may present more than one external interface to other classes or
the same interface may be required from more than one class. An interface in UML is a
group of externally visible (i.e. public) operations. The interface contains no internal
73
structure, it has no attributes, no associations and the implementation of the operations is

not defined. Formally, an interface is equivalent to an abstract class that has no attributes,
no associations and only abstract operations.
The following figure shows two alternative notations for an interface. The simpler of the
two UML interface notations is a circle. This is attached by a solid line to the classes that
support the interface.
The alternative notation uses a stereotyped class icon. As an interface only specifies the
operations and has no internal structure, the attributes compartment is omitted. This
notation lists the operations on the diagram. The realize relationship, represented by the
dashed line with a triangular arrowhead, indicates that the class supports at least the
operations listed in the interface
<< interface >>
Refining Attributes:
In the analysis phase, the name of the attribute was sufficient. However, in the
design phase, detailed information must be added to the model. There are three basic
types of attributes. They are:
1) Single-value attributes.
2) Multiplicity or multi-value attributes.
3) Reference to another object, or instance connection.
Attributes represent the state of an object. The following is the attribute presentation:
Visibility name: type-expression=initial-value
Where visibility is one of the following:
+ public visibility
# protected visibility
- private visibility
During analysis, we identified the following attributes for classes:
74
Refining attributes for Librarian class:

• name
• number
At this stage we need to add more information to these attributes, such as

visibility and implementation type.
+ name : String
+ number: String
Refining attributes for member class:
name
id
After refining
+ id : String
+ name: String
Refining methods:
A class can provide several types of methods.
• Constructor : Method that creates instances of the class.

• Destructor : The method that destroys instances.
• Conversion method: The method that converts a value from one unit of measure
to another.
• Copy method : The method that copies the contents of one instance to another
instance.
• Attribute set : The method that sets the values of one or more attributes.
• I/O methods : The methods that provide or receive data to or from a device.
• Domain specific : The method specific to the application.
The operation syntax is:
Visibility name : (parameter-list) : return-type-expression
Refining methods for Weather Report:
addInfo()
75
deleteInfo()
updateInfo()
After refining
+addInfo (String name,String id)
+deleteInfo (String name, String id)
+updateInfo (String name,String id )
Refining relationships:
The relationships are already been drawn, there are no modifications to be done to
those relationships.
21. REFINED CLASS DIAGRAM
The overall class diagram after refinement is:

76
Weather report
username details
password +1 +1...* state
country
username() date
password()
login() addInfo()
update()
+1
+1
weather reports
user +1...* +1...* Reports(details,state,country,date
view reports()
22. IMPLEMENTATION DIAGRAM

22.a.Component diagram:
77
Component Diagrams show the dependencies between software

components in the system. The nature of these dependencies will depend on the language
or languages used for the development and may exist at compile-time or at runtime.
The component diagram for weather report system:
<<Body>>
<<Header>>
<<includes>> Weather
Weather
Information.h Information.java
<<Object code>>
Weahter
Information.o
22.b. DEPLOYMENT DIAGRAM

78
Deployment Diagrams are used to show the configuration of runtime processing

elements and the software components and processes that are located on them.
PC Client LMSDB: Database
Server:pc
<<JDBC>>
Client:pc
PC Server LMSDB: Database
Aaro/vark:de alpha
<<JDBC>>
Sun:jdbc
Weather info Weather info db
23. Testing
TEST CASE FOR VERIFICATION OF ADMIN:

79
Test Test case Test case step expected act Test case
case id name description ual status
administr Verify .To verify Click submit, with An error F
ator admin that admin out entering admin message
and Username user name and “pls enter
passwrd and passwrd the user
passwrd is name and
greater than passwrd”
6 digit must be
number displayed.
Enter the username An error

and passwrd equal message F
to 6 digit. Say “the
(123456) password
click submit. must be
greater than
6 digit”
must be
displayed.
Display the P
Enter the username further
and passwrd having movement
greater than 6 digit or an error
say (123456) type & message
click submit “invalied
username
and passwrd
” must be
displayed.
TEST CASE FOR GETTING THE TEMPERATURE VALUES:
Test case Test case Test case step expected actual Test
id name description case
status
80
Get Verify .To verify Enter the An error F

temperatur location that location. message
e location is “invalied
value correct or location” must
not be displayed.
Click An error
submit message “enter
with out the location”
entering must be F
the displayed.
location
Enter the
location Display values
type & of temperature
click for given P
submit temperature,city,
date or “invalid
city ” must be
displayed.
24. Implementation screen shots:

81
WELCOME:
ENTRANCESCREEN:
82
USER SCREEN:
83
PRESENTTEMPSCREEN:
PAST TEMPERATURE SCREEN:

84
85
ADMINISTRATORSCREEN:
REPORT UPDATE SCREEN:

86
INSERTING AND EDITING SCREEN:
INSERTING VALUES SCREEN:

87
EDITING THE TEMPERATURES SCREEN:
UPDATING TEMPERATURE SCREEN:

88
DELETING REPORT SCREEN:
LOGOUT SCREEN:
89
25.CONCLUSION:
90
The project report entitled “WAETHER REPORT” has come to its final stage.
The system has been developed with much care that it is free of errors and at the same
time it is efficient and less time consuming. The important thing is that the system is
robust. Also provision is provided for future developments in the system. The entire
system is secured. This thesis submitted by the B.Tech students.
REFERENCES
91
1. http://download.oracle.com/javase/tutorial/
2. http://download.oracle.com/javase/tutorial/jdbc/index.html
3. http://www.developer.com/db/article.php/942641/An-Overview-of-Java-
Database-Connectivity.htm
4. http://www.wilsonmar.com/1jdbc.htm
5. http://www.jsptube.com/
6. http://www.roseindia.net/servlets/index.shtml

Ur Project

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ur Project

Hochgeladen von

Copyright:

Verfügbare Formate

1

MINI PROJECT REPORT

Submitted in partial fulfillment of requirements to

CS 451 – SE/MINI PROJECT LAB

J.LAKSHMAN KUMAR (Y7CS859)

R.V.R & J.C.COLLEGE OF ENGINEERING

R.V.R & J.C.COLLEGE OF ENGINEERING

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

J.Lakshman kumar (Y7CS859), K.Madhu (Y7CS865), K.Suryateja (Y7CS854) who

Mr. R. Mabubasha Dr. G.Satyanarayana Prasad

The successful completion of any task would be incomplete without a proper

We are greatly indebted to our Professor and HOD, Dept., of Information

We express our sincere thanks to our Lecturer In charge, Mr. R.

3. System Requirements Specification 7

5. Identification of Use cases and sub use cases. 16

6. Building requirements model through Use case diagram. 19

8. Prototypes for application. 30

10. Identification of Analysis classes. 37

11. Identify the responsibilities of Classes. 43

12. Use case realizations. 49

13. Sequence diagrams. 53

14. Collaboration diagrams. 53

15. Identification of attributes and methods of classes. 57

16. Identification of relationships among classes. 58

17. UML Class diagram. 59

18. UML state chart diagram. 64

19. Designing classes by applying design axioms. 69

20. Refining attributes, methods & relationships. 70

21. Refined class diagram. 75

22. Implementation diagrams.

22. a. Component diagram. 76

22. b. Deployment diagram. 77

1. Entry of the users.

Database Administrator (administrator) will maintain the database of the system

 Managing the weather details.

3.SYSTEM REQUIREMENTS SPECIFICATIONS

PROCESSOR : PENTUIUM IV 2.6 GHz

RAM : 512MB DD RAM

MONITOR : 15” COLOR

HARD DISK :320 GB

KEYBOARD : STANDARD 102 KEYS

FORNT END :JAVA,HTML,SERVLETS

BACKEND : ORACLE 10g

OPERATING SYSTEM : WINDOWS XP

HyperText Markup Language(HTML):

HyperText Markup Language (HTML), the publishing language of the

Separate structure and presentation:

presentational elements and attributes are being replaced by other mechanisms, in

6)Support for the title and lang attributes on all elements.

7)Support for the ABBR and ACRONYM elements.

INTRODUCTION ABOUT JAVA:

Java is a programming language originally developed by Jame Gosling at Sun

Virtual Machine (JVM) regardless of computer architecture. Java is a general-purpose,

JAVA IS PLATFORM INDEPENDENT:

JAVA DATABASE CONNECTIVITY(JDBC):

About jConnect for JDBC

SERVLETS USING JAVA WEBSERVER:

• Who directly uses the system

5. IDENTIFICATION OF USE-CASES AND SUB USE-CASES

Use-case diagrams graphically represent system behavior (use cases).

 Delivering something of value to the actor.

The basic shape of a use case is an ellipse

Purpose of use cases:

Use-cases identified for our system are: