SYSTEM ABSTRACT Problem statement :The introduction of new technology is a common result of many business imperatives.

Increasing competition, more market deregulation; tighten regulation control on pricing and current economic condition all encourages initiatives that add to the complexity of technology environment. Now a days, communication using computer networks that is internet or intranet is increasing very rapidly. The online chat messengers are becoming popular among the users of Internet for keeping in touch with the Internet. The messengers that are in use, uses server that has to maintain connections of a very large number of clients. The server has to be highly scalable servers. These servers programs need machine or computer with very high resources. In other words, the hardware requirements of the server are high. The hardware of any computer can fail any time due to any particular reasons. Thus, if any part of the hardware requirement fails, the speed of the server reduces drastically or it may even crash. Thus no organization can afford the cost of server failure. SOLUTION:In Instant Messenger, server is built of a technology known as Java NIO (Non Blocking I/O). Before J2SE 1.4, all I/O calls were blocking. When an input or output operation is called, the program would halt until the previous I/O operation is completed, until the optionally configured timeout has expired. In the case of clients and servers this posed many problems. In a single threaded, client server application if a client tries to connect the server while the another client (client A) is connected to the server, client B is blocked until client A disconnects from the server. Concurrent communication is not possible. In a multi-threaded, client server application, concurrent communication with a server from multiple clients required multiple threads. For each incoming client I/O request, a separate server thread is spawned to service the I/O request. For applications with the large number of clients this leads to thread overhead and reducing the scalability of these servers. The new I/O APIs in J2SE 1.4 enables developers to built non blocking I/O, into there applications. With non blocking I/O, when an input or output operation is called, the operation returns immediately with whatever information is available and execution is not halted. Server can now interact with multiple clients connections simultaneously without creating a new thread for each connections. Continuously attempting to read data from each connection wastes processors time. Readiness selection is a mean of making the process of transferring data more efficient. Readiness selection is a simultaneous checking of multiple channels to determine which channels are ready to perform I/O operations. Instead of querying each channel, the

programmer determines which channels are ready with one step. Each ready channel is processed separately and those that are not ready are ignored. Readiness selection is performed with selectors. A selector monitors its registered channels, identifies channel that are ready for I/O and passes client request to the corresponding channels.

Interface selectableChannel (in package java.nio.channels) provides a framework for creation and using non blocking channels. A SelectableChannel is a channel that supports readiness selection, which means that the channel can be queried to determine if it is ready to perform I/O operations. The most useful subclass of SelectableChannel are ServerSocketChannel and SocketChannel. Object of these classes carry on network communication between the server and the client and can work in non-blocking mode. Class Selector (also in package java.nio.channels) provides the selector functionality. Due to java NIO the server can run on a computer having low resources as effectively as another server which is running on a machine having very high resources. This would help in increasing the mean time to fail to the server. It would be very reliable considering the importance of server in client server applications in todays world of communications over Internet and Intranet. In the Instant messenger, mainly file transfer and text messaging is performed. The text messaging facility of the instant messenger is similar to an internet RELAY chat. The text message that is being typed by the user is send of the server by the client program. The server then send the message to all the clients that are connected to it one by one. Thus the message is received by all the users. Instant messenger provides peer to peer file transfer method with a centralized control of the server. The service is responsible for handling the negotiation for initiating the file transfer. After the negotiation is complete then server send the clients IP address of client whom it want to send a file.

Aim :

Study Of Use-Case Diagram.

Theory :
The use-case concept was introduced by Ivar Jacobson in the object-oriented software engineering (OOSE) method. A use-case diagram is a graph of actors, a set of use cases enclosed by a system boundary, communication (participation) associations between the actors and the use cases, and generalization among the cases. Use case diagrams show how users interact with the system. Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how. Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic. "A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. " Used during requirements elicitation to represent external behavior Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment

Actors
An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: client: A person who uses chatting system

Client

Use Cases

A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Pre-conditions Entry conditions (triggers) Flow of events Exit conditions (success guarantees) Special requirements

Login

The <<extend>> Relationship

<<extend>> relationships represent exceptional or seldom invoked cases. The exceptional event flows are factored out of the main event flow for clarity. Use cases representing exceptional flows can extend more than one use case. The direction of a <<extend>> relationship is to the extended use case

The <<include>> Relationship

An <<include>> relationship represents behavior that is factored out of the use case. An <<include>> represents behavior that is factored out for reuse, not because it is an exception. The direction of a <<include>> relationship is to the using use case (unlike <<extend>> relationships).

Use case diagrams are helpful in three areas.

determining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape. communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients. generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

Use case diagram for our system as shown in fig 3.1 USE CASE DIAGRAM

adm in
< < us es > >

server log in
< < us es > >

clie nt

client registration < < us es > >

validation

client lo gin

send m e ssage

send file

server

chat ro om request

lo g out

Conclusion:

From this practical we have learnt how to make Use Case Diagram using Star UMLsoftware in UML.

Practical No: 4 Aim :

Study Of Activity Diagram.

Theory :
An Activity diagram is a visual representation of any system's activities and flows of data or decisions between activities. ctivity diagrams provide a very broad view of a business process. They represent the dynamics of a system. They are flow charts that are used to show the work flow of a system. They show the flow of control from activity to activity in the system. They show what activities can be done in parallel, and any alternative paths through the flow. Purpose Model business workflows Model operations Activity diagrams commonly contain Activity states and action states Transitions Objects

Action States and Activity States

Action states are atomic and cannot be decomposed Work of the action state is not interrupted Activity states can be further decomposed Their activity being represented by other activity diagrams They may be interrupted Represented in UML by a rounded rectangle.

Activity represents the performance of some behavior in the work flow.

Transitions
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. When the action or activity of a state completes, flow of control passes immediately to the next action or activity state A flow of control has to start and end at some place initial state -- a solid ball stop state -- a solid ball inside a circle

Branching
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 transition from a decision point contain a guard condition. The guard condition is used to determine which path from the decision point is taken. Decisions along with their guard conditions allow you to show alternative paths through a work flow. A branch specifies alternate paths taken based on some Boolean expression A branch may have one incoming transition and two or more outgoing ones

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. A synchronization bar may have many incoming transition and one outgoing transition, or one incoming transition and many outgoing transitions. It is use to specify the forking and joining of parallel flows of control A synchronization bar is rendered as a thick horizontal or vertical line

A fork may have one incoming transitions and two or more outgoing transitions each transition represents an independent flow of control conceptually, the activities of each of outgoing transitions are concurrent either truly concurrent (multiple nodes)

or sequential yet interleaved (one node) A join may have two or more incoming transitions and one outgoing transition above the join, the activities associated with each of these paths continues in parallel at the join, the concurrent flows synchronize each waits until all incoming flows have reached the join, at which point one flow of control continues on below the join

Swimlanes
Swimlanes may be used to partition an activity diagram. This facility allows activity diagrams to expand and show who has the responsibility for each activity in a process A swimlane specifies a locus of activities To partition the activity states on an activity diagram into groups each group representing the business organization responsible for those activities each group is called a swimlane Each swimlane is divided from its neighbor by a vertical solid line Each swimlane has a name unique within its diagram Each swimlane may represent some real-world entity Each swimlane may be implemented by one or more classes Every activity belongs to exactly one swimlane, but transitions may cross lanes

The activity diagram for Internet chatting system is shown in fig 4.1 ACTIVITY DIAGRAM
Server : server client : client

Sever login waiting for client Client Registraion Exist user ? ( yes )

( no )

Registraion process

Authenticati on of user

( yes )

Client login ( no )

valid user ( no ) ( yes ) connection established client interface activated chat room ( yes ) ( no ) fetch list

fetch user list

( no ) send? ( no ) receive? ( no ) ( yes ) Receive message log out from chat room ( no )

( yes ) select user receive message/file

Send message/file Sign out from room

log out from system ( yes )

Send message to client

Sign out Remove from room list Refresh room list Connection released

Remove from user list

Refresh user list

Aim :

Study Of Class Diagram And State Diagram

Theory :
CLASS Diagram Overview:
The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application. The class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modelling of object oriented systems because they are the only UML diagrams which can be mapped directly with object oriented languages. The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It is also known as a structural diagram.

Purpose: The purpose of the class diagram is to model the static view of an application.
The class diagrams are the only diagrams which can be directly mapped with object oriented languages and thus widely used at the time of construction.The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the application but class diagram is a bit different. So it is the most popular UML diagram in the coder community. So the purpose of the class diagram can be summarized as:

Analysis and design of the static view of an application. Describe responsibilities of a system. Base for component and deployment diagrams. Forward and reverse engineering.

Notation:
Class Classes are the building blocks in object-oriented programming. A Class is depicted using a rectangle divided into three sections. The top section is the name of the Class. The middle section defines the properties of the Class. The bottom section lists the methods of the class.

Association

An Association is a generic relationship between two classes, and is modeled by a line connecting the two classes. This line can be qualified with the type of relationship, and can also feature multiplicity rules (eg. one-to-one, one-to-many, many-to-many) for the relationship. If a class cannot exist by itself, and instead must be a member of another class, then that class has a Composition relationship with the containing class. A Composition relationship is indicated by a line with a filled diamond. When a class uses another class, perhaps as a member variable or a parameter, and so "depends" on that class, a Dependency relationship is formed. A Dependency relationship is indicated by a dotted arrow. Aggregations indicate a whole-part relationship, and are known as "has-a" relationships. An Aggregation relationship is indicated by a line with a hollow diamond. A Generalization relationship is the equivalent of an inheritance relationship in object-oriented terms (an "is-a" relationship). A Generalization relationship is indicated by an arrow with a hollow arrowhead pointing to the base, or "parent", class.

Composition

Dependency

Aggregation

Generalizati on

How to draw Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software applications. So it is very important to learn the drawing procedure of class diagram. Class diagrams have lot of properties to consider while drawing but here the diagram will be considered from a top level view. Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application. So a collection of class diagrams represent the whole system. The following points should be remembered while drawing a class diagram:

The name of the class diagram should be meaningful to describe the aspect of the system. Each element and their relationships should be identified in advance. Responsibility (attributes and methods) of each class should be clearly identified. For each class minimum number of properties should be specified. Because unnecessary properties will make the diagram complicated. Use notes when ever required to describe some aspect of the diagram. Because at the end of the drawing it should be understandable to the developer/coder. Finally, before making the final version, the diagram should be drawn on plain paper and rework as many times as possible to make it correct.

Now the following diagram is an example of an Order System of an application. So it describes a particular aspect of the entire application.

First of all Order and Customer are identified as the two elements of the system and they have a one to many relationship because a customer can have multiple orders. We would keep Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and NormalOrder. The two inherited classes have all the properties as the Order class. In addition they have additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points mentioned above:

CLASS DIAGRAM
A d m in
us e rn a m e : S t rin g pa s s w o rd : S trin g lo g in()

1 S E RV E R 1 1
s s : S e rverS o c k et m a in ()

0 ..n

1 ..n c lie nt s e nd e r
m ain ()

1 0 ..n s e rvic e r
s c k : S oc k et d o s : D a ta O u tp u tS tre am d in : D a ta Inp u t S tre a m s e rvic er() run () req u es t IP () s e nd m s g () s e nd all()

s e nd _ m s g 1 ..n re c e ive r

1 c ha t ro o m
n a m e : S trin g t y p e : S trin g lim it : in te g e r c h e c k ro o m lis t() roo m d eta ils ()

1 m yfra m e
s c k : S oc k et o s : D a ta O u tp u tS tre a m is : D a ta In pu t S tre a m a d dlis t () m y fram e()

1 file
s h o w file () c o m p re s s ()

R unna b le

J F ra m e

Aim :

Study Of Interaction Diagram (Sequence And Collaboration Diagram).

Theory :
SEQUENCE Diagram A sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. Sequence diagrams contain the following: Class roles (subsystem/object/class, actor, and external system roles in the interaction). These are (usually) drawn across the top of the diagram. Lifelines (subsystem/object/class existence). These (usually) extend down the diagram. Activations (show when the subsystem/object/class is doing something) Messages (communication between roles) Class Roles Notation is a rectangle containing RoleName:ClassName (both underlined) Can be an interface instead of class. May have a number in the upper right hand corner giving the number of instances involved. Represents an object, class, actor (person), subsystem or external system. RoleName:ClassName

Lifelines Dashed or dotted line from past to future or from birth to death if a role with a limited lifespan. Death is marked with a large May split and merge to represent alternative paths. E.g.,

Activation Shown by a box over a lifeline Represents an active role May call itself recursively Messages Denoted by labeled horizontal arrows If simply an arrow, represents flow of control.

If shown as:

} paired
represents a handshake (e.g., TCP). If with a half-arrowhead, asynchronous (e.g., UDP):

If at an angle rather than horizontal, represents a time delay:

Sequence diagram for our system is shown in fig SEQUENCE DIAGRAM

SERVER : client login(uname,pwd) Open GUI() Acknowledgement Verify uname and pwd Return (true)

DB

-: CLIENT LOGIN :-

: admin Login(uname,pwd)

Server Verify (uname,pwd) Return(true)

DB

connection established()

-: SERVER LOGIN :-

: client

SERVER

DB

Registration request( ) Registration form( ) submit( ) Store_details() Create account() Return(true)

-: REGISTRATION :-

Client1 : client

SERVER

DB Client2 : client

send_msg(uname,msg) request IP(uname) send IP( ) send ACK() send_msg(msg,IP)

-: SEND MESSAGE (PRIVATE) :-

C lie n t1 : c li e n t

SE RV ER

DB C lie n t2 : c li e C tlie n t3 : c li e n t n

s e n d a ll(m s g )

r e q u e s t_ u s e rli s t( ) s e n d _ u s e rlis t( ) re q u e s t a ll IP ( ) s e n d a ll IP ( ) s e n d _ m s g (m s g )

s e nd A C K ( )

s e nd _ m s g (m s g )

-: SEND MESSAGE (PUBLIC) :-

Client1 : client

SERVER request IP(dname)

DB

C lient2 : client

file request(fname, sname,uname )

send IP( ) check file status( fname) status(true) compress(fname) send file size(fname) allow file(true,sname) send file(fname,sname) request IP(sname) send IP( )

send file(fname, IP) Acknowledgement( )

-: FILE TRANSFER :-

: client request room( )

SERVER fetch room details( )

DB

send room details( ) select room( ) check roomlist(room) return(true) open GUI( )

-: CHAT ROOM LOGIN :-

: client sign out(uname)

SERVER

DB

close GUI( uname)

update list(uname )

-: LOG OUT :Conclusion:

From this practical we have learnt how to make Sequence Diagram using Star UMLsoftware in UML.

COLLABORATION Diagram :Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links. Collaboration diagrams show (used to model) how objects interact and their roles. They are very similar to sequence diagrams. Actually they are considered as a cross between class and sequence diagram. Sequence Diagrams are arranged according to Time. Collaboration Diagrams represent the structural organization of object. [Both sequence and collaboration diagrams are called interaction diagrams] Forms a context for interactions May realize use cases May be associated with operations May describe the static structure of classes Collaboration diagrams contain the following: Class roles (subsystems/objects/classes/actors/ external systems) as before. Association roles (pathways or links over which messages flow) Message flows (messages sent between class roles) Association Roles Often classes Define the interaction between class roles.

Role-Name:Association-Name Multiplicity
Multiplicities defined if the Class Roles represent sets of objects

Multiplicity

Message Flows Sequence numbers on every message. These can be nested to associate related messages. Arrows are the same as those used in sequence diagrams.

Collaboration diagrams for our system is shown in fig

1: Login(uname,pwd) Server : admin 4: connection established()

3: Return(true)

2: Verify (uname,pwd)

DB

-:Server Login:-

1: login(uname,pwd) 5: Acknowledgement SERVE R : client 4: Open GUI()

3: Return (true) 2: Verify uname and pwd

DB

-:Client Login:-

1: Registration request( ) 3: submit( ) 2: Registration form( ) 6: Create account()

SERVER

: client

5: Return(true) 4: Store_details()

DB

Registration
1: send_msg(uname,msg) SERVER Client1 : client 5: send ACK()

3: send IP( ) 4: send_msg(msg,IP) 2: request IP(uname)

DB Client2 : client

Send Message(Private)

1: send all(msg) SERVER Client1 : client 8: send ACK( )

2: request_userlist( ) 4: request all IP( ) DB 3: send_userlist( ) 5: send all IP( )

7: send_msg(msg) 6: send_msg(msg)

Client2 : client

Client3 : client

Send Message (Public)

DB C lient1 : client 2: request IP(dname) 10: request IP (sname) 12: send file(fname, IP )

1: file request(fname,sna me,uname)

3: send IP ( ) 11: send IP( )

SE RV ER

4: check file status( fname) 6: compress(fname) 8: allow file(true,sname) 13: A cknowledgement( ) 5: status(true) 7: send file size(fname) 9: send file(fname,sname)

C lient2 : client

File Transfer

1: request room( ) 4: select room( ) 3: send room details( ) 7: open GUI( )

SERVER

: client

6: return(true)

2: fetch room details( ) 5: check roomlist(room)

DB

Chat Room Login

1: sign out(uname) 2: close GUI( uname)

SERVER

: client

3: update list(uname )

DB

Log Out

Conclusion:
From this practical we have learnt how to make Collaboration Diagram using Star UMLsoftware in UML

STATECHART Diagram Overview:

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different states of a component in a system. The states are specific to a component/object of a system. A Statechart diagram describes a state machine. Now to clarify it state machine can be defined as a machine which defines different states of an object and these states are controlled by external or internal events.

Purpose:
Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system. They define different states of an object during its lifetime. And these states are changed by events. So Statechart diagrams are useful to model reactive systems. Reactive systems can be defined as a system that responds to external or internal events. Statechart diagram describes the flow of control from one state to another state. States are defined as a condition in which an object exists and it changes when some event is triggered. So the most important purpose of Statechart diagram is to model life time of an object from creation to termination. Following are the main purposes of using Statechart diagrams:

To model dynamic aspect of a system. To model life time of a reactive system. To describe different states of an object during its life time. Define a state machine to model states of an object.

Notation :
State The State notation marks a mode of the entity, and is indicated using a rectange with rounded corners, and the state name written inside. Transition A Transition marks the changing of the object State, caused by an event. The notation for a Transition is an arrow, with the Event Name written above, below, or alongside the arrow. Initial State The Initial State is the state of an object before any transitions. For

Final State

objects, this could be the state when instantiated. The Initial State is marked using a solid circle. Only one initial state is allowed on a diagram. End States mark the destruction of the object who's state we are modeling. These states are drawn using a solid circle with a surrounding circle.

How to draw Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life cycle. So the emphasis is given on the state changes upon some internal or external events. These states of objects are important to analyze and implement them accurately. Statechart diagrams are very important for describing the states. States can be identified as the condition of objects when a particular event occurs. Before drawing a Statechart diagram we must have clarified the following points:

Identify important objects to be analyzed. Identify the states. Identify the events.

The following is an example of a Statechart diagram where the state of Order object is analyzed. The first state is an idle state from where the process starts. The next states are arrived for events like send request, confirm request, and dispatch order. These events are responsible for state changes of order object. During the life cycle of an object (here order object) it goes through the following states and there may be some abnormal exists also. This abnormal exit may occur due to some problem in the system. When the entire life cycle is complete it is considered as the complete transaction as mentioned below. The initial and final state of an object is also shown below.

Where to use Statechart Diagrams?

From the above discussion we can define the practical applications of a Statechart diagram. Statechart diagrams are used to model dynamic aspect of a system like other four diagrams disused in this tutorial. But it has some distinguishing characteristics for modeling dynamic nature. Statechart diagram defines the states of a component and these state changes are dynamic in nature. So its specific purpose is to define state changes triggered by events. Events are internal or external factors influencing the system. Statechart diagrams are used to model states and also events operating on the system. When implementing a system it is very important to clarify different states of an object during its life time and statechart diagrams are used for this purpose. When these states and events are identified they are used to model it and these models are used during implementation of the system. If we look into the practical implementation of Statechart diagram then it is mainly used to analyze the object states influenced by events. This analysis is helpful to understand the system behavior during its execution. So the main usages can be described as:

To model object states of a system.

To model reactive system. Reactive system consists of reactive objects. To identify events responsible for state changes. Forward and reverse engineering.

Conclusion:
From this practical we have learnt how to make State Chart Diagram using Star UMLsoftware in UML

STATE CHART DIAGRAM SERVER

R e c e iv e M s g d o / r e c e iv e m s g ( )

Se n d M sg d o / r e c e iv e I P ( ) d o /se n d m sg (IP ) d o / s e n d a ll( ) I d l el o g i n ( uo nn a m e , p w d ) R e c e iv e F ile S hu t D o w n

e x it / d is c o n n e c t c lie n t ( ) d o / r e c e iv e f ile ( ) d o / c h e c k s iz e ( )

S e n d F ile d o / r e c e iv e I P ( ) d o / s e n d f ile ( I P )

C ha t R o o m d o / f e t c h r o o m lis t ( ) d o / c h e c k r o o m lis t ( )

CLIENT

e s t a b lis h c o n n e c t io n e n try /o p e n G U I() d o / a d d lis t ( )

Send M sg d o /s e n d m s g () d o / s e n d a l l( )

R e c e iv e M s g d o / r e c e iv e m s g ( )

I d le

R e g is t e r lo g in ( u n a m e , p w d ) on e n try /re q u e st() d o / f illf o r m ( )

S e n d F ile d o /c h e c k s ta tu s () d o /c o m p re s s (fn a m d o / s e n d f ile ( d n a m e

C l o s e C co l no ns ee Gc tUi o I n ed ) o / s i g n o u t ( ) )e x i t / r e m o v e f r o m l i s t ( )

R e c e iv e F ile d o / r e c e i v e f il e ( s n a m e ) d o / s h o w f ile ( ) d o / s a v e f i le ( p a t h )

C hat R oom e d d d d d d e n o o o o o o x try /re q u e s t() / s e le c t r o o m ( ) /o p e n G U I() /s e n d m s g () / r e c e iv e m s g ( ) / s e n d f ile ( ) / r e c e iv e f ile ( ) it / lo g o u t ( )

Aim :

Study Of Component Diagram

Theory :
COMPONENT Diagram Overview:
Component diagrams are different in terms of nature and behavior. Component diagrams are used to model physical aspects of a system. Physical aspects are the elements like executables, libraries, files, documents etc which resides in a node.So component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems.

Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also different from all other diagrams discussed so far. It does not describe the functionality of the system but it describes the components used to make those functionalities. So from that point component diagrams are used to visualize the physical components in a system. These components are libraries, packages, files etc. Component diagrams can also be described as a static implementation view of a system. Static implementation represents the organization of the components at a particular moment. A single component diagram cannot represent the entire system but a collection of diagrams are used to represent the whole. So the purpose of the component diagram can be summarized as:

Visualize the components of a system. Construct executables by using forward and reverse engineering. Describe the organization and relationships of the components.

Notation :
Component

A component represents a software entity in a system. Examples include source code files, programs, documents, and resource files. A

component is represented using a rectangular box, with two rectangles protruding from the left side, as seen in the image to the right.
Dependency

A Dependency is used to model the relationship between two components. The notation for a dependency relationship is a dotted arrow, pointing from a component to the component it depends on.

COMPONENT DIAGRAM

<<Infrastructure>>

<<GUI>>

SERVER

CLIENT

SQL Server

Conclusion:
From this practical we have learnt how to make Component Diagram using Star UMLsoftware in UML.

Aim :

Study Of Deployment Diagram

Theory :
DEPLOYMENT Diagram Overview:
Deployment diagrams are used to visualize the topology of the physical components of a system where the software components are deployed. So deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their relationships.

Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for describing the hardware components where software components are deployed. Component diagrams and deployment diagrams are closely related. Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware. UML is mainly designed to focus on software artifacts of a system. But these two diagrams are special diagrams used to focus on software components and hardware components. So most of the UML diagrams are used to handle logical components but deployment diagrams are made to focus on hardware topology of a system. Deployment diagrams are used by the system engineers. The purpose of deployment diagrams can be described as:

Visualize hardware topology of a system. Describe the hardware components used to deploy software components. Describe runtime processing nodes.

Notation :
Component A component represents a software entity in a system. Examples include source code files, programs, documents, and resource files. On a deployment diagram, components are placed within nodes to identify their deployed location. A component is represented using a rectangular box, with two rectangles protruding from the left side, as seen in the image to the right. A node represents a piece of hardware in the system. This entity is represented by a threedimensional cube.

Node

Association

An association, drawn as a solid line between two Nodes, indicates a line of communication between the hardware elements.

How to draw Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to the component diagram. Because the components are deployed using the deployment diagrams. A deployment diagram consists of nodes. Nodes are nothing but physical hardwares used to deploy the application. Deployment diagrams are useful for system engineers. An efficient deployment diagram is very important because it controls the following parameters

Performance Scalability Maintainability Portability

DEPLOYMENT DIAGRAM

Server

1 1
<<TCP / IP>>

server catlog server catlog java server 1

Client user interface * file interface swing

HTTP / FTP

DATABASE
<<Ethernet>>

1 SQL server

JDBC

Conclusion:
From this practical we have learnt how to make Deployment Diagram using Star UMLsoftware in UML.