UNIT-V

ArchitecturalModeling:Component,Deployment,ComponentdiagramsandDeployme
ntdiagrams.

UNIT-V

Components

 Acomponentisaphysicalandreplaceablepartofasystemthatconformstoandprovidesthe
realization ofaset of interfaces.

 Youusecomponentstomodelthephysicalthingsthatmayresideonanode,suchasexecutabl
es,libraries, tables, files, and documents.

 Acomponenttypicallyrepresentsthephysicalpackagingofotherwiselogicalelements,suc
h as classes, interfaces, and collaborations.

 IntheUML,allthesephysicalthingsaremodeledascomponents.Acomponentisaphysical
thingthat conforms toand realizes asetofinterfaces

 TheUMLprovidesagraphicalrepresentationofacomponent,asbelowfigureshows.

 Thiscanonicalnotationpermitsyoutovisualizeacomponentapartfromanyoperatingsyste
m or programminglanguage.

 Usingstereotypes,oneoftheUML'sextensibilitymechanisms,youcantailorthisnotationto
represent specifickinds of components.

Fig:Components

TermsandConcepts
 Acomponentisaphysicalandreplaceablepartofasystemthatconformstoandprovidesthe
realization ofaset of interfaces.
 Graphically,a componentisrenderedasarectanglewithtabs.

Names

 Everycomponent musthaveaname that distinguishesit fromother components.

 Anameis atextual string.Thatname aloneisknown asasimplename.

 A path name is the component name prefixed by the name of the package in
whichthatcomponent lives.

 A component is typically drawn showing only its name, as in below figure. Just
aswithclasses,youmaydrawcomponentsadornedwithtaggedvaluesorwithadditionalcom
partments toexposetheirdetails, asyouseeinthefigure.

Fig: Simple and Extended Components

Components and Classes

Similarities
 Componentsarelikeclasses
 Bothhavenames
 Bothmayrealizeaset of interfaces
 Bothmayparticipateindependency,generalization,andassociationrelationships
 Both maybenested
 Bothmayhaveinstances
 Bothmaybeparticipantsin interactions.

Therearesomesignificant differences betweencomponentsandclasses.

 Classesrepresentlogicalabstractions;componentsrepresentphysicalthingsthatlivei
n theworld of bits.
 Inshort,components mayliveon nodes,classesmaynot.
 Componentsrepresentthephysicalpackagingofotherwiselogicalcomponentsandare
at a different level of abstraction.
 Classes mayhaveattributes and
operationsdirectly.Ingeneral,componentsonlyhaveoperations that arereachable
onlythroughtheirinterfaces.

Asbelowfigureshows,therelationshipbetweenacomponentandtheclassesitimplements can
be shown explicitly by using a dependency relationship. Most of thetime, you'll never
need to visualize these relationships graphically. Rather, you will keepthemas apart
ofthecomponent's specification.
 Fig: Components and

ClassesComponentsandInterfaces

 Aninterfaceisacollectionofoperationsthatareusedtospecifyaserviceofaclassor
acomponent.

 Therelationshipbetweencomponentandinterface isimportant.

 All the most common component-based operating system facilities (such as

COM+,CORBA, and Enterprise Java Beans) use interfaces as the glue that binds
componentstogether.

 Usingoneofthesefacilities,youdecomposeyourphysicalimplementationbyspecifyingint
erfaces thatrepresent themajorseams in thesystem.

 Youthenprovidecomponentsthatrealizetheinterfaces,alongwithothercomponentsthat
access theservices throughtheirinterfaces.
 Thismechanismpermitsyoutodeployasystemwhoseservicesaresomewhatlocation-
independentand, asdiscussed inthe next section,replaceable.

 Asbelowfigureindicates,youcanshowtherelationshipbetweenacomponentanditsinterfa
ces inoneof two ways.

 The first(andmostcommon) style renders the interface initselided,iconic form.The

component that realizes the interface is connected to the interface using an
elidedrealizationrelationship.

 The second style renders the interface in its expanded form, perhaps revealing
itsoperations.

 The component that realizes the interface is connected to the interface using a
fullrealizationrelationship.In bothcases,thecomponentthataccesses the servicesof the
 othercomponentthroughtheinterfaceisconnectedtotheinterfaceusingadependency
relationship.

Fig:ComponentsandInterfaces

 An interface that a component realizes is called an export interface, meaning

aninterfacethat the component providesas aserviceto othercomponents.

 A componentmayprovide manyexportinterfaces.

 Theinterfacethatacomponentusesiscalledanimportinterface,meaninganinterfacethat
the component conforms to and so builds on.

 A component may conform to many import interfaces. Also, a component may

bothimportand export interfaces.

 A given interfacemaybeexported byonecomponentand imported byanother.

 Thefactthatthisinterfaceliesbetweenthetwocomponentsbreaksthedirectdependencybet
ween thecomponents.

 Acomponentthatusesagiveninterfacewillfunctionproperlynomatterwhatcomponent
realizes that interface. Of course, a component can be used in a context ifand only if
all its import interfaces are provided by the export interfaces of othercomponents.

Deployment

 A node is a physical element that exists at run time and represents a

computationalresource,generallyhavingatleast some memoryand, often,
processingcapability.

 Youusenodestomodelthetopologyofthehardwareonwhichyoursystemexecutes.

 A node typically represents a processor or a device on which components may

bedeployed.
 TheUMLprovidesa graphicalrepresentationof node,asbelow figureshows.

 This canonical notationpermitsyou to visualize a node apart from any

specifichardware. Usingstereotypes oneof theUML'sextensibilitymechanisms.

 You can (and often will) tailor this notation to represent specific kinds of
processorsanddevices.

Figure:Nodes

TermsandConcepts
 A node is a physical element that exists at run time and represents a
computationalresource,generallyhavingatleast some memoryand, often,
processingcapability.

 Graphically,anodeis renderedasacube.

Names
 Everynodemusthave a name thatdistinguishesitfromothernodes.

 Anameis atextual string.Thatname alone isknown asasimplename.

 A path name is the node name prefixed by the name of the package inwhich
thatnodelives.

 A node is typically drawn showing only its name, as in below figure. Just as
withclasses,youmaydrawnodesadornedwithtaggedvaluesorwithadditionalcompartmen
tsto exposetheirdetails.

Fig:SimplenamesandPathnames
NodesandComponents

Similarities
 Inmanyways, nodesare alot likecomponents:
 Bothhavenames;
 Bothmayparticipateindependency,generalization,andassociation relationships
 Both maybenested;
 Both mayhaveinstances;
 Bothmaybeparticipantsininteractions.

Therearesomesignificantdifferencesbetweennodesandcomponents.

 Componentsarethingsthatparticipateintheexecutionofasystem;nodesarethingsthat
execute components.
 Componentsrepresentthephysicalpackagingofotherwiselogicalelements;
Codesrepresentthephysicaldeploymentofcomponents.
 Thisfirstdifferenceisthemostimportant.Simplyput,nodesexecutecomponents;comp
onents arethings that areexecuted bynodes.

 As below figure shows, the relationship between a node and the components
itdeploys can be shown explicitly by using a dependency relationship. Most of
thetime, you won't need to visualize these relationships graphically but will
keepthemas apart ofthenode's specification.

Fig:NodesandComponents

Asetofobjectsorcomponentsthatareallocatedtoanodeasagroupiscalleda
distributionunit.

OrganizingNodes

 Youcanorganizenodesbygroupingtheminpackagesinthesamemannerinwhichyoucan
organizeclassesand components.
 Youcanalsoorganizenodesbyspecifyingdependency,generalization,andassociation(incl
udingaggregation) relationshipsamongthem.

Connections
 Themostcommonkindof relationshipyou'lluse amongnodesisanassociation.
 In this context, an association represents a physical connection among nodes, such
asanEthernetconnection, aserial line, orashared bus,
 As below figure shows. You can even use associations to model indirect
connections,suchas asatellite link between distant processors.

Fig:Connections

 Becausenodesareclass-like,youhavethefullpowerofassociationsatyourdisposal.
 Thismeansthat you can includeroles,multiplicity,and constraints.
 As in the previous figure, you should stereotype these associations if you want
tomodel new kinds of connections for example, to distinguish between a 10-T
Ethernetconnectionandan RS-232 serial connection.

ComponentDiagrams
 Component diagrams are one of the two kinds of diagrams found in modeling
thephysicalaspects of object-oriented systems.

 A component diagram shows the organization and dependencies among a set

ofcomponents.

 Youusecomponent diagramstomodel thestaticimplementationviewofa system.

 This involves modeling the physical things that reside on a node, such as
executables,libraries,tables, files,and documents.

 TheUMLprovidesagraphicalrepresentationofacomponent,asbelowfigureshows.

 Thiscanonicalnotationpermitsyoutovisualizeacomponentapartfromanyoperatingsyste
m or programminglanguage.

 Usingstereotypes,oneoftheUML'sextensibilitymechanisms,youcantailorthisnotationto
represent specifickinds of components.

Fig:Components

 Componentdiagramsareessentiallyclassdiagramsthatfocusonasystem'scomponents.

 Componentdiagramsarenotonlyimportantforvisualizing,specifying,anddocumenting
component-based systems, but also for constructing executable
systemsthroughforward and reverseengineering.

 With the UML, you use component diagrams to visualize the static aspect of
thesephysicalcomponentsandtheirrelationshipsandtospecifytheirdetailsforconstruction
,as shown infigure

Fig:ComponentDiagram

TermsandConcepts
 Acomponentdiagramshowsasetofcomponentsandtheirrelationships.Graphically,a
component diagramis acollectionofverticesandarcs.

 Everycomponent musthaveaname that distinguishesit fromother components.

 Anameis atextual string.Thatname aloneisknown asasimplename.

 A path name is the component name prefixed by the name of the package in
whichthatcomponent lives.

 A component is typically drawn showing only its name, as in below figure. Just
aswithclasses,youmaydrawcomponentsadornedwithtaggedvaluesorwithadditionalcom
partments toexposetheirdetails, asyouseeinthefigure.

Fig: Simple and Extended

CommonProperties

 A component diagram is just a special kind of diagram and shares the same
commonpropertiesasdoallotherdiagramsanameandgraphicalcontentsthatareaprojectio
n into a model.What distinguishesa component diagramfromall otherkindsof
diagrams is its particular content.

Contents

Componentdiagrams commonlycontain
 Components
 Interfaces
 Dependency,generalization,association,andrealizationrelationships
 Likeallotherdiagrams,componentdiagramsmaycontainnotesandconstraints.
  Componentdiagramsmayalsocontainpackagesorsubsystems,bothofwhichar
eused togroup elementsofyourmodelinto largerchunks.

CommonUses

 Youusecomponent diagramstomodel thestaticimplementationviewofa system.

 This view primarily supports the configuration management of a system's parts,
madeupof componentsthatcanbe assembledinvariouswaystoproducea runningsystem.
 When you model the static implementation view of a system, you'll typically
usecomponentdiagrams in oneof fourways.

1Tomodelsourcecode
 Withmostcontemporaryobject-
orientedprogramminglanguages,you'llcutcodeusingintegrated
developmentenvironments thatstore yoursourcecodein files.
 Youcanusecomponentdiagramstomodeltheconfigurationmanagementofthesefiles,whi
ch represent work-product components.

2. Tomodelexecutablereleases
 A release is a relatively complete andconsistent set of artifacts delivered to
aninternalor external user.
 In the context of components, a release focuses on the parts necessary to deliver
arunning system.Whenyoumodela release using
componentdiagrams,youarevisualizing, specifying, and documenting the decisions
about the physical parts thatconstitute your software•that is, itsdeployment
components.

3. Tomodelphysical databases
 Think of a physical database as the concrete realization of a schema, living in
theworldof bits.
 Schemas, in effect, offer an API to persistent information; the model of a
physicaldatabaserepresentsthestorageofthatinformationinthetablesofarelationaldataba
seor thepages ofan object-oriented database.
 Youusecomponentdiagramstorepresenttheseandotherkindsofphysicaldatabases.

4.Tomodeladaptablesystems
 Somesystemsare quitestatic;their componentsenter thescene,participate
inanexecution,and then depart.
 Othersystemsaremoredynamic,involvingmobileagentsorcomponentsthatmigrate
forpurposes of loadbalancingand failurerecovery.
 YouusecomponentdiagramsinconjunctionwithsomeoftheUML'sdiagramsformodeling
behavior to represent thesekinds of systems.

Common Modeling

TechniquesModelingSourceCo

de

Tomodelasystem'ssourcecode

 Eitherbyforwardorreverseengineering,identifythesetofsourcecodefilesofinterestand
model themascomponents stereotyped as files.
 Forlargersystems,usepackagestoshowgroupsofsource codefiles.

 Consider exposing a tagged value indicating such information as the version

numberof the source code file, its author, and the date it was last changed. Use tools
tomanagethe value ofthistag.

 Model the compilation dependencies among these files using dependencies.

Again,usetools to help generateand managethesedependencies.

 For example, below figure shows five source code files. signal.h is a header
file.Threeofitsversionsareshown,tracingfromnewversionsbacktotheirolderancestors.
Eachvariantof this source code file is renderedwith a taggedvalueexposingits version
number.

Fig:ModelingSourceCode

Modeling an Executable

ReleaseTomodelan

executablerelease

 Identify the set of components you'd like to model. Typically, this will involve
someor all the components that live on one node, or the distribution of these sets
ofcomponentsacrossall the nodes in thesystem.

 Consider the stereotype of each component in this set. For most systems, you'll find
asmall number of different kinds of components (such as executables, libraries,
tables,files, and documents). You can use the UML's extensibility mechanisms to
providevisualcues forthesestereotypes.

 For each component in this set, consider its relationship to its neighbors. Most
often,thiswillinvolveinterfacesthatareexported(realized)bycertaincomponentsand
 then imported (used) by others. If you want to expose the seams in your
system,modeltheseinterfacesexplicitly.Ifyouwantyourmodelatahigherlevelofabstractio
n,elidetheserelationshipsbyshowingonlydependenciesamongthecomponents.

 For example, below figure models part of the executable release for an
autonomousrobot. This figure focuses on the deployment components associated with
the robot'sdriving and calculation functions. You'll find one component (driver.dll)
that
exportsaninterface(IDrive)thatis,inturn,importedbyanothercomponent(path.dll).driver.
dllexportsoneotherinterface(ISelfTest)thatisprobablyusedbyothercomponents in the
system, althoughthey are not shown here. There'sone
othercomponentshowninthisdiagram(collision.dll),andit,too,exportsasetofinterfaces,
although these details are elided: path.dll is shown with a
dependencydirectlytocollision.dll.

Fig: Modeling an Executable

ReleaseModelinga Physical Database

Tomodelaphysicaldatabase

 Identifytheclassesinyour modelthatrepresentyourlogicaldatabaseschema.

 Select a strategy for mapping these classes to tables. You will also want to
considerthe physical distribution ofyourdatabases. Your mapping strategy willbe
affectedbythe locationin whichyouwantyour datato liveonyour deployedsystem.

 To visualize, specify, construct, and document your mapping, create a

componentdiagramthat contains components stereotypedastables.

 Where possible, use tools to help you transform your logical design into a
physicaldesign.

 Below figure shows a set of database tables drawn from an information system for
aschool. You will find one database (school.db, rendered as a component
stereotypedas database) that's composed of five tables: student, class, instructor,
department, andcourse (rendered as a component stereotyped as table, one of the
UML's standardelements). In the corresponding logical database schema, there was
no inheritance, somappingto this physicaldatabasedesign is straightforward.
 Fig: Modeling a Physical

DatabaseModelingAdaptableSystems

Tomodelan adaptablesystem

 Consider the physical distribution of the components that may migrate from node
tonode.

 You can specify the location of a component instance by marking it with a

locationtaggedvalue,whichyoucanthenrenderinacomponentdiagram(although,technica
llyspeaking,adiagramthat containsonlyinstances isan objectdiagram).

 Ifyouwanttomodeltheactionsthatcauseacomponenttomigrate,createacorrespondinginte
raction diagram thatcontains component instances.

 You can illustrate a change of location by drawing the same instance more than
once,butwith different valuesforits locationtagged value.

 For example, below figure models the replication of the database from the
previousfigure.Weshowtwoinstancesofthecomponentschool.db.Bothinstancesareanon
ymous, and both have a different value for their location tagged value. There'salsoa
note, which explicitlyspecifieswhich instancereplicates theother.

Fig:ModelingAdaptableSystems
ForwardandReverseEngineering:Thecreation ofcodefromamodel

Toforwardengineeracomponentdiagram

 Foreachcomponent,identifytheclassesorcollaborationsthatthecomponentimplements.

 Choose the target for each component. Your choice is basically between source
code(aformthatcanbemanipulatedbydevelopmenttools)orabinarylibraryorexecutable(a
form that can bedroppedintoarunningsystem).

 Usetoolstoforward engineeryourmodels.

Reverseengineering(thecreationofamodelfromcode)acomponentdiagramisnotaperfectpro
cess becausethereis alwaysaloss of information.

Toreverseengineeracomponentdiagram

 Choosethetargetyouwanttoreverseengineer.Sourcecodecanbereverseengineeredtocom
ponentsandthenclasses.Binarylibrariescanbereverseengineered to uncover their
interfaces. Executables can be reverse engineered theleast.

 Using a tool, point to the code you'd like to reverse engineer. Use your tool
togenerate a new model or to modify an existing one that was previously
forwardengineered.

 Using your tool, create a component diagram by querying the model. For
example,you might start with one or more components, then expand the diagram by
followingrelationshipsorneighboringcomponents.Exposeorhidethedetailsofthecontent
softhis component diagram as necessaryto communicateyour intent.

 For example, below figure provides a component diagram that represents the
reverseengineeringoftheActiveXcomponentvbrun.dll.Asthefigureshows,thecomponen
t realizes 11 interfaces. Given this diagram,you can beginto understandthesemantics
ofthe component bynext exploringthe details of its interfaces.

Fig:ReverseEngineering
DeploymentDiagrams

 Deploymentdiagramsareoneofthetwokindsofdiagramsusedinmodelingthephysicalaspe
cts ofan object-oriented system.
 Adeploymentdiagramshowstheconfigurationofruntimeprocessingnodesandthecompon
entsthat live on them.
 Youusedeploymentdiagrams tomodel thestaticdeploymentview ofasystem.
 For the most part, this involves modeling the topology of the hardware on which
yoursystemexecutes.
 Deploymentdiagramsareessentiallyclassdiagramsthatfocuson asystem'snodes.
 Deploymentdiagramsarenotonlyimportantforvisualizing,specifying,anddocumenting
embedded, client/server, and distributed systems, but also for
managingexecutablesystems through forward and reverseengineering.

 With the UML, you use deployment diagrams to visualize the static aspect of
thesephysical nodes and their relationships and to specify their details for
construction, asinbelow figure.

Fig:ADeploymentDiagram

TermsandConcepts

 Adeploymentdiagramisadiagramthatshowstheconfigurationofruntimeprocessingnodes
and thecomponents that live on them.
 Graphically,adeploymentdiagramisacollection ofverticesandarcs.
CommonProperties

A deployment diagram is just a special kind of diagram and shares the same
commonproperties as all other diagrams a name and graphical contents that are a
projection into amodel. What distinguishes a deployment diagram from all other kinds of
diagrams is itsparticularcontent.

Contents

Deploymentdiagramscommonlycontain

 Nodes
 Dependencyandassociationrelationships
 Likeallotherdiagrams,deploymentdiagramsmaycontainnotesandconstraints
.
 Deploymentdiagramsmayalsocontaincomponents,eachofwhichmustliveon
somenode.
 Deploymentdiagramsmayalsocontainpackages orsubsystems,

CommonUses

Whenyoumodelthe staticdeploymentview of asystem,you'lltypicallyuse

deploymentdiagramsin oneof threeways.

1. Tomodelembeddedsystems
 An embedded system is a software-intensive collection of hardware that
interfaceswiththephysical world.
 Embedded systems involve software that controls devices such as motors,
actuators,and displays and that, in turn, is controlled by external stimuli such as
sensor input,movement,and temperaturechanges.
 You can use deployment diagrams to model the devices and processors that
compriseanembedded system.

2. Tomodelclient/serversystems
 Aclient/serversystemisacommonarchitecturefocusedonmakingaclearseparation of
concerns between the system's user interface (which lives on the client)andthe
system's persistent data(which lives ontheserver).
 Client/server systemsare one endof the continuumof distributedsystemsandrequireyou
to make decisions about the network connectivity of clients to serversand about the
physical distribution of your system's software components across thenodes.
 You can model the topologyof such systems byusingdeployment diagrams.

3. Tomodelfullydistributedsystems
 Attheotherendofthecontinuumofdistributedsystemsarethosethatarewidely,ifnotgloball
y, distributed, typicallyencompassingmultiple levels ofservers
 Suchsystemsareoftenhoststomultipleversionsofsoftwarecomponents,someofwhichma
yeven migratefrom nodeto node.
 Craftingsuchsystemsrequiresyoutomakedecisionsthatenablethecontinuouschangeinthe
system'stopology.Youcanusedeploymentdiagramstovisualizethe
 system'scurrenttopologyanddistributionofcomponentstoreasonabouttheimpactofchang
es on that topology.

Common Modeling
TechniquesModelinganEmbed
dedSystem

Tomodelanembeddedsystem

 Identifythedevices andnodesthat areuniquetoyoursystem.

 Provide visual cues, especially for unusual devices, by using the UML's
extensibilitymechanisms to define system-specific stereotypes with appropriate icons.
At the veryleast, you'll want to distinguish processors (which contain software
components) anddevices(which, at thatlevel of abstraction, don'tdirectlycontain
software).
 Modeltherelationshipsamongtheseprocessorsanddevicesinadeploymentdiagram.
Similarly, specify the relationship between the components in your
system'simplementationview andthe nodesinyoursystem's deploymentview.
 As necessary, expand on any intelligent devices by modeling their structure with
amoredetailed deployment diagram.
 For example, below figure shows the hardware for a simple autonomous robot.
You'llfindonenode(Pentiummotherboard)stereotyped asaprocessor.

Fig: Modeling an Embedded

SystemModelinga Client/ServerSystem

Tomodelaclient/serversystem

 Identifythenodesthatrepresentyoursystem'sclientandserverprocessors.

 Highlightthosedevicesthataregermanetothebehaviorofyoursystem.Forexample, you'll
want to model special devices, such as credit card readers, badgereaders, and display
devices other than monitors, because their placement in thesystem's
hardwaretopologyarelikelyto be architecturallysignificant.

 Providevisualcues fortheseprocessors anddevices viastereotyping.

 Model the topology of these nodes in a deployment diagram. Similarly, specify
therelationship between the components in your system's implementation view and
thenodesinyour system's deployment view.

 For example, below figure shows the topology of a human resources system,
whichfollows a classical client/server architecture. This figure illustrates the
client/serversplit explicitly by using the packages named client and server. The client
packagecontainstwonodes(consoleandkiosk),bothofwhicharestereotypedandarevisuall
y distinguishable. The server package contains two kinds of nodes (cachingserver and
server), and both of these have been adorned with some of the componentsthat reside
on each. Note also that caching server and server are marked with
explicitmultiplicities, specifying how many instances of each are expected in a
particulardeployed configuration. For example, this diagram indicates that there may
be two ormorecachingservers in anydeployed instanceof thesystem.

Fig:Modeling a Client/Server

SystemModelinga Fully Distributed System

Tomodelafullydistributedsystem

 Identifythesystem'sdevicesandprocessorsasforsimplerclient/serversystems.

 If you need to reason about the performance of the system's network or the impact
ofchanges to the network, be sure to model these communication devices to the level
ofdetailsufficient to maketheseassessments.

 Pay close attention to logical groupings of nodes, which you can specify by
usingpackages.

 Model these devices and processors using deployment diagrams. Where possible,
usetoolsthatdiscoverthetopologyofyour systembywalkingyoursystem'snetwork.

 If you need to focus on the dynamics of your system, introduce use case diagrams
tospecify the kinds of behavioryou are interestedin, and expand on these use
caseswithinteraction diagrams.

 Belowfigureshowsthetopologyofafullydistributedsystem.Thisparticulardeployment
diagram is also an object diagram, for it contains only instances. You
canseethreeconsoles(anonymousinstancesofthestereotypednodeconsole),whichare
 linked to the Internet (clearly a singleton node). In turn, there are three instances
ofregional servers, which serve as front ends of country servers, only one of which
isshown. As the note indicates, country servers are connected to one another, but
theirrelationshipsarenot shown in this diagram.

Fig: Modeling a Fully Distributed

SystemForwardand ReverseEngineering

 There's only a modest amount of forward engineering (the creation of code

frommodels)thatyoucan dowithdeployment diagrams.
 For example, after specifying the physical distribution of components across
thenodesina deploymentdiagram,itispossible touse toolsthat then
pushthesecomponents out to the real world. For system administrators, using the
UML in thiswayhelpsyou visualizewhat can beaverycomplicated task.

Reverse engineering (the creation of models from code) from the real world back
todeployment diagrams is of tremendous value, especially for fully distributed systems
thatareunder constant change.
 You'll want to supply a set of stereotyped nodes that speak the language of
yoursystem's network administrators, in order to tailor the UML to their domain.
TheadvantageofusingtheUMListhatitoffersastandardlanguagethataddressesnotonl
ytheirneeds,but theneedsofyourproject'ssoftwaredevelopers,aswell.

Toreverseengineeradeploymentdiagram

 Choose the target that you want to reverse engineer. In some cases, you'll want
tosweepacrossyour entirenetwork; inothers,youcan limityoursearch.

 Choose also the fidelity of your reverse engineering. In some cases, it's sufficient
toreverse engineer just to the level of all the system's processors; in others, you'll
wanttoreverse engineer thesystem's networkingperipherals, as well.

 Use a tool that walks across your system, discovering its hardware topology.
Recordthat topologyin a deployment model.
 Along the way,you canuse similar tools to discover the components that live oneach
node, which you can also record in a deployment model. You'll want to use
anintelligentsearch,forevenabasicpersonalcomputercancontaingigabytesofcomponent
s,manyof which maynot berelevant toyour system.

 Usingyour modelingtools,createadeployment diagram byqueryingthemodel.

 For example, you might start with visualizing the basic client/server topology,
thenexpand on the diagram by populating certain nodes with components of interest
thatlive on them. Expose or hide the details of the contents of this deployment
diagram asnecessaryto communicateyour intent.
UNIT-VI
CaseStudy:TheUnifiedLibrary application,ATMapplication.

UNIT-VI

TheUnifiedLibraryapplication

Introduction
UnifiedLibraryApplicationSystememphasizesontheonlinereservation,
issue and return ofbooks. This system globalizes the present library system. Using
thisapplicationthe membercanreserve any bookfromanywhere inthe world.Still
innascentstages, thisapplication soon revolutionizespresent librarysystem.

Letus justhavean overviewof theunifiedlibraryapplicationsystem:

 Librarianlendsbooksandmagazines
 Librarianmaintains thelistof all themembers of library
 Borrowermakesreservationonline
 Borrowercanremovereservationonline
 Librarianissuesbookstotheborrower
 Librariancalculatesduestobepaid bytheborrower
 Borrowerissues/returnsbooksand/ormagazines
 Librarianplacesorderabouttherequirementstothemasterlibrarian
 Librarianupdatessystem
 Masterlibrarianmaintainslibrarians

TextualAnalysis
(a) Actors
i. Librarian
ii. Borrower
iii. Catalog
iv. MasterLibrarian
(b) Verbs
i. Borrower:
1. Logsintothesystem
2. Browses/searchesforbooksormagazines
3. Makes/removesreservation
 4. Viewsresultsandreportsfromtheunifiedlibraryapplicationsystem
ii. Librarian:
1. Managesandvalidatesmembers
2. Viewreportsfrom thesystem
3. Issuesbooks
4. Calculatesdues
5. Takesbooks
6. Placesorderstothemasterlibrarian
7. Maintainslistofbooksandmagazine
iii. MasterLibrarian
1. Maintainsotherlibrarians
USECASEDIAGRAM:

Usecasediagramiscreatedtovisualizetheinteractionofoursystemwiththeoutsideworld.
Thecomponents of usecasediagram are:
UseCase:Scenarios ofthesystem
Actor:Someoneor somethingwhois
interactingwiththesystemRelationship:Semantic linkbetween
usecaseandactor.

ObjectOrientedAnalysisanddesign,Dept.ofCSE,RGMCET
ACTIVITYDIAGRAM:

Activitydiagramshows the flowofevents

withinoursystem.Thecomponents are:
a) StartState
b) EndState
c) Transition
d) DecisionBox
e) SynchronizationBar
f) SwimLane

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
INTERACTIONDIAGRAM:

An interaction diagram models the dynamic aspects of the system by

showingthe relationship among the objects and messages they may dispatch. There
are twotypesof interaction diagrams:

SEQUENCEDIAGRAM:
Sequencediagramshowsthesteptostepwhatmushhappentoaccomplishapieceof
functionalityprovided bythe system. Thecomponents are:
a) Actor
b) Object
c) Messages
d) Lifeline
e) FocusofControl

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
COLLABORATIONDIAGRAM:
Collaboration diagram displaysobject interactions organizedaroundobjectsand
theirlinksto oneanother. The components are:
a) Actor
b) Object
c) Link

CLASSDIAGRAM:

Classdiagramshowsstructureofthesoftwaresystem.Theclassdiagramshowsasetof
classes, interfacesandtheirrelationships. Thecomponentsare:
a) Class
b) Relationship:
Theformsofrelationshipare:
1. Association
2. Aggregation
3. Generalization
4. Composition
5. Dependency

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
STATECHARTDIAGRAM:
Statechartdiagramshowalifecycleofasingleclass.Thestateisaconditionwherethe
object maybein. Thecomponents are:
a) Startstate
b) End state
c) State
d) Transition

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
Member: Librarian:

LibraryAdministrator:

ATMapplication

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
Introduction:
ATM system needs enhancement to record card information electronically
isautomatically displays the details in the card. The ATM will communicate with the
bankcomputeroveranappropriatecommunicationlink.TheATMwillserveonecustomerata
time. A customer will be required to insert an ATM card and enter a PIN number bothof
which will be sent to bank for valuation as a part of each transaction. The customerwill
then be able to perform one or more transactions. The card will be retained in themachine
until the customer indicates that he/she desires no further transactions, at whichpointit
will bereturned.

Objective:
ThemainobjectiveoftheATMsystemistofacilitatetheuserwitheasytransaction of
money at a faster rate. The ATM application will run automatically andthere will be no
need of any manual interventions. Some built in functions are providedwhich performs
the depositorywith-drawl functions.

Scope:
ThescopeoftheprojectoftheATMsystemistounderstandtheworkingofthesystemandals
o toprovide moresecuritytotheuseras itfacilitateswith easytransaction.

ProblemStatement:
Theoperations onthefunction ofthe ATM areas follows:
1. Thecard has to beinserted in theplaceof theprovided.
2. Asthesystemacceptsthecard itdisplays thenameand otherdetails ofthe user.
3. Itasksforthe password,whichis exclusivelyassignedfortheparticularcard.
4. Ifthecodeiscorrectthen thesystem getsactivated withdetails.

Withdraw usecasediagram:-

+sselectingcash

+modeofpayment

+EnterAmount

+Useraskedforamount +selecting
Controller ATM
User

+variousmethodsofpayment

Withdraw cashusecasediagram:-

+cashisprovidefromsystem +updatingdatabase

ATM Database
user

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
Withdrawsequencediagram:-

user controller ATM

1:user isusedforamount

2: entertheamount

3:userisprovidedwithvariousmodesofpayments

4:selectmodesofpayments

5:selecting cash()

sequence
diagram

6: selectingcheque()

sequence
diagram

Withdraw cashsequencediagram:-

user ATM database

1:cashisprovidedfromsystem

2:updatingdatabase

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
 Withdrawcollaboration:-

2:entertheamount
4:selectmodeofpayment
user controller

1: userisaskedforamount

3:userisprovidedwithvariousmodesofpayment

5:selectingcash

6:selectingcheque

ATM

Withdrawcashcollaboration:-

user

1:cashisprovidedfromthesystem

2:updatingdatabase
ATM database

Withdraw classdiagram:-

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
Withdrawcashclassdiagram:-

StateTransition diagram:

start login validuser

loggedon

invalidlogin
relogin transition

withdrawl

logout updation
transactioncompleted

stop

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET
ComponentDiagram:-

LoginController localbank

Login user

accountinfoand

PerformTransaction TransactionManager

DeploymentDiagram:-

WAN

transactionmanager

transactionmanager
localbank

Activitydiagram:-

ObjectOrientedAnalysisanddesign,Dept.ofCSE, RGMCET