E Messaging Final

8/2/2019 E Messaging Final

1/43


2/43

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 channelthat are ready for I/O and passes client request to the corresponding channels.


3/43

Interface selectableChannel (in package java.nio.channels) provides a framework

for creation and using non blocking channels. A SelectableChannel is a channel thatsupports 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 networkcommunication 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 aseffectively 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. Thetext 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 themessage 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 initiatingthe file transfer. After the negotiation is complete then server send the clients IP address of

client whom it want to send a file.


4/43

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 systemboundary, 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 whata system does rather than how.

Use case diagrams are closely connected to scenarios. A scenario is an example ofwhat 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 andschedules 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

Use Cases

Client


5/43

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

The Relationship 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 relationship is to the extended use case

The Relationship An relationship represents behavior that is factored out of the use case.

An represents behavior that is factored out for reuse, not because it is anexception.

The direction of a relationship is to the using use case (unlike

relationships).

Use case diagrams are helpful in three areas.

determining features (requirements). New use cases often generate newrequirements 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.

Login


6/43

server log in

admi

client registration

client lo

chat room request

client

send message

send file

log o u

serv

validatio


7/43

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


8/43

Practical No: 4

Aim : Study Of Activity Diagram.

Theory :

An Activity diagram is a visual representation of any system's activities and flowsof 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 diagramsThey 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.


9/43

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


10/43

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 inparallel

at the join, the concurrent flows synchronize

each waits until all incoming flows have reached the join, at which pointone flow of control continues on below the join


11/43

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


12/43

Severlogin

waitingfor client

Client

Registraion

Authentication of user

valid user

connectionestablished

receivemessage/file

Send messageto client

Remove fromroom list

Refreshroom list

Connectionreleased

Remove fromuser list

Refreshuser list

Exist user ?

Registraionprocess

Client login( yes ) ( no )

client interfaceactivated

fetchuser list

chat room fetch list

send?

selectuser

( yes )

receive?( no )

Receivemessage

( yes )

log out fromchat room( no )

Sendmessage/file

log out fromsystem

( no )

Sign outfrom room

Sign out

( no )

( yes )

( yes )

( no )

( yes )

( no )

( no )

( yes )

client : clientServer : server

The activity diagram for Internet chatting system is shown in fig 4.1

ACTIVITY DIAGRAM


13/43

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 asystem 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 directlywith 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 codercommunity.

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 inobject-oriented programming. A

Class is depicted using a rectangle

divided into three sections. The topsection is the name of the Class.

The middle section defines theproperties of the Class. The bottom

section lists the methods of the

class.


14/43

Association An Association is a genericrelationship between two classes,

and is modeled by a line connectingthe 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) forthe relationship.

Composition If a class cannot exist by itself, and

instead must be a member ofanother class, then that class has a

Composition relationship with thecontaining class. A Composition

relationship is indicated by a linewith a filled diamond.

Dependency When a class uses another class,

perhaps as a member variable or a

parameter, and so "depends" onthat class, a Dependency

relationship is formed. ADependency relationship is indicated

by a dotted arrow.

Aggregation Aggregations indicate a whole-partrelationship, and are known as

"has-a" relationships. An

Aggregation relationship is indicatedby a line with a hollow diamond.

Generalizati

on

A Generalization relationship is the

equivalent of an inheritancerelationship in object-oriented terms

(an "is-a" relationship). AGeneralization relationship is

indicated by an arrow with a hollow

arrowhead pointing to the base, or"parent", class.

How to draw Class Diagram?


15/43

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 representthe 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. Becauseunnecessary 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 plainpaper 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 Orderand Customerare identified as the two elements of the system andthey 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) SpecialOrderandNormalOrder.

The two inherited classes have all the properties as the Orderclass. In addition they

have additional functions like dispatch () and receive ().

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

above:


16/43


17/43

J F r a m e

1 0 ..n

A dmi nusername : Str ing

password : Str ing

login()

1

1

serv i cer

s c k : S oc k e t

dos : DataOutputSt ream

din : DataInputStream

servicer()

run()

requestIP()

sendmsg()

sendall()

Runnable

S E RV ER

ss : ServerSocket

main()

chat roo m

name : St r ing

type : Str ing

limit : integer

checkroomlis t ( )

roomdetails()

1

0..n

1

1

m yfram e

s c k : S oc k e t

os : DataOutputSt ream

is : DataInputStream

addlist()

myf rame()

file

showfile()

compress()

1

1

1

1

c l ient

main()

s e n d e r

rece i v1..n

1 ..

s e n d _ m

CLASS DIAGRAM

Aim : Study Of Interaction Diagram (Sequence And Collaboration Diagram).


18/43

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


19/43

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:

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:

} paired


20/43

Sequence diagram for our system is shown in fig

SEQUENCE DIAGRAM

: client

SERVER DB

login(uname,pwd)Verify uname and pwd

Return (true)Open GUI()

Acknowledgement

-: CLIENT LOGIN :-

: admin Server DB

Login(uname,pwd)Verify (uname,pwd)

Return(true)connection established()

-: SERVER LOGIN :-


21/43

: clientSERVER DB

Registration request( )

Registration form( )

submit( )Store_details()

Return(true)Create account()

-: REGISTRATION :-

Client1 : clientSERVER DB

Client2 : client

send_msg(uname,msg) request IP(uname)

send IP( )

send_msg(msg,IP)send ACK()

-: SEND MESSAGE (PRIVATE) :-


22/43

C li e n t 1 : c l i e n tS E R V E R D B

C li e n t2 : c l ie n tC li e n t 3 : c li e n t

s e n d a ll(m s g ) r e q u e s t_ u s e r li s t ( )

s e n d _ u s e r li s t ( )

r e q u e s t a l l IP ( )

s e n d a ll IP ( )

s e n d _ m s g ( m s g )

s e n d _ m s g ( m s g )s e n d A C K ( )

-: SEND MESSAGE (PUBLIC) :-


23/43

Client1 : client SERVER DBClient2 : client

file request(fname,sname,uname )

request IP(dname)

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 fi le(fname, IP) Acknowledgement( )

-: FILE TRANSFER :-


24/43

: clientSERVER DB

request room( ) fetch room details( )

send room details( )

select room( )check roomlist(room)

return(true)

open GUI( )


25/43

-: CHAT ROOM LOGIN :-

: client

SERVER DB

sign out(uname)

close GUI( uname)update list(uname )

-: LOG OUT :-

Conclusion:

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


26/43

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

Multiplicities defined if the Class Roles represent sets of objects

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.

Role-Name:Association-Name

Multiplicity Multiplicity


27/43

Collaboration diagrams for our system is shown in fig

: admin

Server

DB

1: Login(uname,pwd)

2: Verify (uname,pwd)

3: Return(true)

4: connection established()

-:Server Login:-


28/43

: client

SERVER

DB

1: login(uname,pwd)

2: Verify uname and pwd

3: Return (true)

4: Open GUI()

5: Acknowledgement

-:Client Login:-


29/43

: client

SERVER

DB

1: Registration request( )

2: Registration form( )

3: submit( )

4: Store_details()

5: Return(true)

6: Create account()

Registration

Client1 : client

SERVER

DB

Client2 : client

1: send_msg(uname,msg)

2: request IP(uname)

3: send IP( )

4: send_msg(msg,IP)

5: send ACK()

Send Message(Private)


30/43

Client1 : client

SERVER DB

Client2 : clientClient3 : client

1: send all(msg)2: request_userlist( )

3: send_userlist( )

4: request all IP( )

5: send all IP( )

6: send_msg(msg)

7: send_msg(msg)

8: send ACK( )

Send Message (Public)

Client1 : client

DB

SERVER

Client2 : client

1: file

request(fname,sna

me,uname)

2: request IP(dname)

3: send IP( )

4: check file status( fname)

5: status(true)

6: compress(fname)

7: send file size(fname)

8: allow file(true,sname)

9: send file(fname,sname)

10: request IP(sname)

11: send IP( )

12: send file(fname, IP)

13: Acknowledgement( )

File Transfer


31/43

: client

SERVER

DB

1: request room( )

2: fetch room details( )

3: send room details( )

4: select room( )

5: check roomlist(room)

6: return(true)

7: open GUI( )

Chat Room Login

: client

SERVER

DB

1: sign out(uname)

2: close GUI( uname)

3: update list(uname )

Log Out


32/43

Conclusion:

From this practical we have learnt how to make Collaboration Diagram using StarUMLsoftware in UML


33/43

STATECHART Diagram Overview:

The name of the diagram itself clarifies the purpose of the diagram and other details. Itdescribes 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 arecontrolled 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 arechanged 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 istriggered. 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 indicatedusing a rectange with rounded

corners, and the state name

written inside.

Transition A Transition marks the changing of

the object State, caused by anevent. The notation for a

Transition is an arrow, with theEvent Name written above, below,

or alongside the arrow.

Initial State The Initial State is the state of an

object before any transitions. For


34/43

objects, this could be the state

when instantiated. The InitialState is marked using a solid

circle. Only one initial state is

allowed on a diagram.

Final State End States mark the destruction ofthe object who's state we are

modeling. These states are drawn

using a solid circle with asurrounding 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 statesof 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 forevents likesend 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 statesand 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.


35/43

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 dynamicin 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 objectduring 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 toanalyze 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.


36/43

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 StarUMLsoftware in UML


37/43

I d l el o g i n ( u n a m e , p w d )

R e c e i v e M

d o / r e c e i v

o n

S e n d M s

d o / r e c e i vd o / s e n d md o / s e n d a

R e c e i v e F i l e

d o / r e c e i v e f i l e ( )d o / c h e c k

S e n d F i l e

d o / r e c e i v

d o / s e n d f i

C h a t R o o

d o / f e t c h r od o / c h e c

S h u t D o w

e x i t / d i s c o

STATE CHART DIAGRAM

SERVER


38/43

I d l eR e g i s t e r

e n t r y / r e q u e s t ( )d o / f i l l f o r m ( )

o nl o g i n ( u n a m e , p w d )

e s t a b l i s h c o n n e

e n t r y / o p e n G U Id o / a d d l i s t ( )

S e n d M s g

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

R e c e i v e M s g

d o / r e c e i v e m s g

S e n d F i l e

d o / c h e c k s t a t u s ( )d o / c o m p r e s s ( f n a m e )d o / s e n d f i l e ( d n a m e )

R e c e i v e F i l e

d o / r e c e i v e f i l e (d o / s h o w f i l e ( )d o / s a v e f i l e ( p a

C h a t R o o m

e n t r y / r e q u e s td o / s e l e c t r o o md o / o p e n G U I ( )d o / s e n d m s g ( )d o / r e c e i v e m s gd o / s e n d f i l e ( )d o / r e c e i v e f i l ee x i t / l o g

C l o s e C o n

d o / s i g n o u t ( )e x i t / r e m

c l o

CLIENT


39/43

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

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 softwareentity in a system. Examples include

source code files, programs,documents, and resource files. A


40/43

SERVER

CLIENT

L erver

component is represented using arectangular box, with two rectangles

protruding from the left side, as seenin 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, pointingfrom a component to the component it

depends on.

COMPONENT DIAGRAM

Conclusion:

From this practical we have learnt how to make Component Diagram using StarUMLsoftware in UML.


41/43

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 nameDeploymentitself describes the purpose of the diagram. Deployment diagramsare 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 diagramsare special diagrams used to focus on software components and hardware components.

So most of the UML diagrams are used to handle logical components but deploymentdiagrams 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.


42/43

Notation :

Component A component represents asoftware entity in a system.

Examples include source code files,programs, documents, and

resource files. On a deployment

diagram, components are placedwithin nodes to identify their

deployed location. A component isrepresented using a rectangular

box, with two rectangles

protruding from the left side, as

seen in the image to the right.Node A node represents a piece of

hardware in the system. This

entity is represented by a three-dimensional cube.

Association An association, drawn as a solid

line between two Nodes, indicatesa line of communication betweenthe hardware elements.

How to draw Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to thecomponent 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 isvery important because it controls the following parameters

Performance

Scalability

Maintainability

Portability


43/43

Server 1 Client *

DATABASE 1

1

*1

1

server catlog

server catlog

java server

user interface

file i nterface

swing

SQL server

HTTP / FTP

JDBC

DEPLOYMENT DIAGRAM

Conclusion:

From this practical we have learnt how to make Deployment Diagram using StarUMLsoftware in UML.

E Messaging Final

Documents

Transcript of E Messaging Final