UNIT-V

Architectural Modeling: Component, Deployment, Component diagrams and

Deployment diagrams.

UNIT-V

Components

• A component is a physical and replaceable part of a system that conforms to and

provides the realization of a set of interfaces.

• You use components to model the physical things that may reside on a node, such as
executables, libraries, tables, files, and documents.

• A component typically represents the physical packaging of otherwise logical

elements, such as classes, interfaces, and collaborations.

• In the UML, all these physical things are modeled as components. A component is a
physical thing that conforms to and realizes a set of interfaces

• The UML provides a graphical representation of a component, as below figure

shows.

• This canonical notation permits you to visualize a component apart from any
operating system or programming language.

• Using stereotypes, one of the UML's extensibility mechanisms, you can tailor this
notation to represent specific kinds of components.

Fig: Components

Terms and Concepts

• A component is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces.
• Graphically, a component is rendered as a rectangle with tabs.

Names

• Every component must have a name that distinguishes it from other components.

• A name is a textual string. That name alone is known as a simple name.

• A path name is the component name prefixed by the name of the package in which
that component lives.

• A component is typically drawn showing only its name, as in below figure. Just as
with classes, you may draw components adorned with tagged values or with
additional compartments to expose their details, as you see in the figure.

Fig: Simple and Extended Components

Components and Classes

Similarities
• Components are like classes
• Both have names
• Both may realize a set of interfaces
• Both may participate in dependency, generalization, and association relationships
• Both may be nested
• Both may have instances
• Both may be participants in interactions.

There are some significant differences between components and classes.

• Classes represent logical abstractions; components represent physical things that

live in the world of bits.
• In short, components may live on nodes, classes may not.
• Components represent the physical packaging of otherwise logical components
and are at a different level of abstraction.
• Classes may have attributes and operations directly. In general, components only
have operations that are reachable only through their interfaces.

As below figure shows, the relationship between a component and the classes it
implements can be shown explicitly by using a dependency relationship. Most of the
time, you'll never need to visualize these relationships graphically. Rather, you will keep
them as a part of the component's specification.
 Fig: Components and Classes

Components and Interfaces

• An interface is a collection of operations that are used to specify a service of a class

or a component.

• The relationship between component and interface is important.

• All the most common component-based operating system facilities (such as COM+,
CORBA, and Enterprise Java Beans) use interfaces as the glue that binds components
together.

• Using one of these facilities, you decompose your physical implementation by

specifying interfaces that represent the major seams in the system.

• You then provide components that realize the interfaces, along with other
components that access the services through their interfaces.
• This mechanism permits you to deploy a system whose services are somewhat
location-independent and, as discussed in the next section, replaceable.

• As below figure indicates, you can show the relationship between a component and
its interfaces in one of two ways.

• The first (and most common) style renders the interface in its elided, iconic form.
The component that realizes the interface is connected to the interface using an elided
realization relationship.

• The second style renders the interface in its expanded form, perhaps revealing its
operations.

• The component that realizes the interface is connected to the interface using a full
realization relationship. In both cases, the component that accesses the services of the
 other component through the interface is connected to the interface using a
dependency relationship.

Fig: Components and Interfaces

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

interface that the component provides as a service to other components.

• A component may provide many export interfaces.

• The interface that a component uses is called an import interface, meaning an

interface that the component conforms to and so builds on.

• A component may conform to many import interfaces. Also, a component may both
import and export interfaces.

• A given interface may be exported by one component and imported by another.

• The fact that this interface lies between the two components breaks the direct
dependency between the components.

• A component that uses a given interface will function properly no matter what
component realizes that interface. Of course, a component can be used in a context if
and only if all its import interfaces are provided by the export interfaces of other
components.

Kinds of Components
Three kinds of components may be distinguished.

First, there are deployment components.

• These are the components necessary and sufficient to form an executable system,
such as dynamic libraries (DLLs) and executables (EXEs).
• The UML's definition of component is broad enough to address classic object
models, such as COM+, CORBA, and Enterprise Java Beans, as well as
 alternative object models, perhaps involving dynamic Web pages, database
tables, and executables using proprietary communication mechanisms.

Second, there are work product components.

• These components are essentially the residue of the development process,
consisting of things such as source code files and data files from which
deployment components are created.
• These components do not directly participate in an executable system but are the
work products of development that are used to create the executable system.

Third are execution components.

• These components are created as a consequence of an executing system, such as a
COM+ object, which is instantiated from a DLL.

Organizing Components
• You can organize components by grouping them in packages in the same manner
in which you organize classes.
• You can also organize components by specifying dependency, generalization,
association (including aggregation), and realization relationships among them.

Standard Elements

The UML defines five standard stereotypes that apply to components:

Common Modeling Techniques

Modeling Executables and Libraries

To model executables and libraries

• Identify the partitioning of your physical system. Consider the impact of technical,
configuration management, and reuse issues.

• Model any executables and libraries as components, using the appropriate standard
elements. If your implementation introduces new kinds of components, introduce a
new appropriate stereotype.

• If it's important for you to manage the seams in your system, model the significant
interfaces that some components use and others realize.

• As necessary to communicate your intent, model the relationships among these

executables, libraries, and interfaces. Most often, you'll want to model the
dependencies among these parts in order to visualize the impact of change.
• For example, below figure shows a set of components drawn from a personal
productivity tool that runs on a single personal computer. This figure includes one
executable (animator.exe, with a tagged value noting its version number) and four
libraries (dlog.dll, wrfrme.dll, render.dll, and raytrce.dll), all of which use the UML's
standard elements for executables and libraries, respectively. This diagram also
presents the dependencies among these components.

Fig: Modeling Executables and Libraries

Modeling Tables, Files, and Documents

To model tables, files, and documents

• Identify the ancillary components that are part of the physical implementation of your
system.

• Model these things as components. If your implementation introduces new kinds of

artifacts, introduce a new appropriate stereotype.

• As necessary to communicate your intent, model the relationships among these

ancillary components and the other executables, libraries, and interfaces in your
system. Most often, you'll want to model the dependencies among these parts in order
to visualize the impact of change.

• For example, below figure builds on the previous figure and shows the tables, files,
and documents that are part of the deployed system surrounding the executable
animator.exe. This figure includes one document (animator.hlp), one simple file
(animator.ini), and one database table (shapes.tbl), all of which use the UML's
standard elements for documents, files, and tables, respectively.
 Fig: Modeling Tables, Files, and Documents

Modeling an API

To model an API

• Identify the programmatic seams in your system and model each seam as an
interface, collecting the attributes and operations that form this edge.

• Expose only those properties of the interface that are important to visualize in the
given context; otherwise, hide these properties, keeping them in the interface's
specification for reference, as necessary.

• Model the realization of each API only insofar as it is important to show the
configuration of a specific implementation.

• Figure exposes the APIs of the executable in the previous two figures. You'll see four
interfaces that form the API of the executable: IApplication, IModels, IRendering,
and IScripts.

Fig: Modeling an API

Modeling Source Code

To model source code

• Depending on the constraints imposed by your development tools, model the files
used to store the details of all your logical elements, along with their compilation
dependencies.

• If it's important for you to bolt these models to your configuration management and
version control tools, you'll want to include tagged values, such as version, author,
and check in/check out information, for each file that's under configuration
management.

• As far as possible, let your development tools manage the relationships among these
files, and use the UML only to visualize and document these relationships.

• For example, below figure shows some source code files that are used to build the
library render.dll from the previous examples. This figure includes four header files
(render.h, rengine.h, poly.h, and colortab.h) that represent the source code for the
specification of certain classes. There is also one implementation file (render.cpp)
that represents the implementation of one of these headers.

Fig: Modeling Source Code

Deployment

• A node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and, often, processing capability.

• You use nodes to model the topology of the hardware on which your system
executes.

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

deployed.
• The UML provides a graphical representation of node, as below figure shows.

• This canonical notation permits you to visualize a node apart from any specific
hardware. Using stereotypes one of the UML's extensibility mechanisms.

• You can (and often will) tailor this notation to represent specific kinds of processors
and devices.

Figure: Nodes

Terms and Concepts

• A node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and, often, processing capability.

• Graphically, a node is rendered as a cube.

Names
• Every node must have a name that distinguishes it from other nodes.

• A name is a textual string. That name alone is known as a simple name.

• A path name is the node name prefixed by the name of the package in which that
node lives.

• A node is typically drawn showing only its name, as in below figure. Just as with
classes, you may draw nodes adorned with tagged values or with additional
compartments to expose their details.

Fig: Simple names and Path names

Nodes and Components

Similarities
• In many ways, nodes are a lot like components:
• Both have names;
• Both may participate in dependency, generalization, and association relationships
• Both may be nested;
• Both may have instances;
• Both may be participants in interactions.

There are some significant differences between nodes and components.

• Components are things that participate in the execution of a system; nodes are
things that execute components.
• Components represent the physical packaging of otherwise logical elements;
Codes represent the physical deployment of components.
• This first difference is the most important. Simply put, nodes execute
components; components are things that are executed by nodes.

• As below figure shows, the relationship between a node and the components it
deploys can be shown explicitly by using a dependency relationship. Most of the
time, you won't need to visualize these relationships graphically but will keep
them as a part of the node's specification.

Fig: Nodes and Components

A set of objects or components that are allocated to a node as a group is called a

distribution unit.

Organizing Nodes

• You can organize nodes by grouping them in packages in the same manner in which
you can organize classes and components.
• You can also organize nodes by specifying dependency, generalization, and
association (including aggregation) relationships among them.

Connections
• The most common kind of relationship you'll use among nodes is an association.
• In this context, an association represents a physical connection among nodes, such as
an Ethernet connection, a serial line, or a shared bus,
• As below figure shows. You can even use associations to model indirect connections,
such as a satellite link between distant processors.

Fig: Connections

• Because nodes are class-like, you have the full power of associations at your
disposal.
• This means that you can include roles, multiplicity, and constraints.
• As in the previous figure, you should stereotype these associations if you want to
model new kinds of connections for example, to distinguish between a 10-T Ethernet
connection and an RS-232 serial connection.

Common Modeling Techniques

Modeling Processors and Devices

To model processors and devices

• Identify the computational elements of your system's deployment view and model
each as a node.
• If these elements represent generic processors and devices, then stereotype them as
such. If they are kinds of processors and devices that are part of the vocabulary of
your domain, then specify an appropriate stereotype with an icon for each.
• As with class modeling, consider the attributes and operations that might apply to
each node.
• For example, below figure takes the previous diagram and stereotypes each node.
The server is a node stereotyped as a generic processor; the kiosk and the console are
nodes stereotyped as special kinds of processors; and the RAID farm is a node
stereotyped as a special kind of device.

Fig: Processors and Devices

Modeling the Distribution of Components

To model the distribution of components

• For each significant component in your system, allocate it to a given node.

• Consider duplicate locations for components. It's not uncommon for the same kind of
component (such as specific executables and libraries) to reside on multiple nodes
simultaneously.

• Render this allocation in one of three ways.

1. Don't make the allocation visible, but leave it as part of the
backplane of your model that is, in each node's specification.
2. Using dependency relationships, connect each node with the
components it deploys.
3. List the components deployed on a node in an additional
compartment.

• Below figure takes the earlier diagrams and specifies the executable components that
reside on each node. This diagram is a bit different from the previous ones in that it is
an object diagram, visualizing specific instances of each node. In this case, the RAID
farm and kiosk instances are both anonymous and the other two instances are named
(c for the console and s for the server). Each processor in this figure is rendered with
an additional compartment showing the component it deploys. The server object is
also rendered with its attributes (processorSpeed and memory) and their values
visible.

Fig: Modeling the Distribution of Components.

Component Diagrams
• Component diagrams are one of the two kinds of diagrams found in modeling the
physical aspects of object-oriented systems.

• A component diagram shows the organization and dependencies among a set of

components.

• You use component diagrams to model the static implementation view of a system.
• This involves modeling the physical things that reside on a node, such as executables,
libraries, tables, files, and documents.

• Component diagrams are essentially class diagrams that focus on a system's

components.

• Component diagrams are not only important for visualizing, specifying, and
documenting component-based systems, but also for constructing executable systems
through forward and reverse engineering.

• With the UML, you use component diagrams to visualize the static aspect of these
physical components and their relationships and to specify their details for
construction, as shown in figure

Fig: Component Diagram

Terms and Concepts

• A component diagram shows a set of components and their relationships.
Graphically, a component diagram is a collection of vertices and arcs.

Common Properties

• A component diagram is just a special kind of diagram and shares the same common
properties as do all other diagrams a name and graphical contents that are a
projection into a model. What distinguishes a component diagram from all other
kinds of diagrams is its particular content.

Contents

Component diagrams commonly contain

• Components
• Interfaces
• Dependency, generalization, association, and realization relationships
• Like all other diagrams, component diagrams may contain notes and
constraints.
 • Component diagrams may also contain packages or subsystems, both of
which are used to group elements of your model into larger chunks.

Common Uses

• You use component diagrams to model the static implementation view of a system.
• This view primarily supports the configuration management of a system's parts, made
up of components that can be assembled in various ways to produce a running
system.
• When you model the static implementation view of a system, you'll typically use
component diagrams in one of four ways.

1 To model source code

• With most contemporary object-oriented programming languages, you'll cut code
using integrated development environments that store your source code in files.
• You can use component diagrams to model the configuration management of these
files, which represent work-product components.

2. To model executable releases

• A release is a relatively complete and consistent set of artifacts delivered to an
internal or external user.
• In the context of components, a release focuses on the parts necessary to deliver a
running system. When you model a release using component diagrams, you are
visualizing, specifying, and documenting the decisions about the physical parts that
constitute your software• that is, its deployment components.

3. To model physical databases

• Think of a physical database as the concrete realization of a schema, living in the
world of bits.
• Schemas, in effect, offer an API to persistent information; the model of a physical
database represents the storage of that information in the tables of a relational
database or the pages of an object-oriented database.
• You use component diagrams to represent these and other kinds of physical
databases.

4. To model adaptable systems

• Some systems are quite static; their components enter the scene, participate in an
execution, and then depart.
• Other systems are more dynamic, involving mobile agents or components that
migrate for purposes of load balancing and failure recovery.
• You use component diagrams in conjunction with some of the UML's diagrams for
modeling behavior to represent these kinds of systems.

Common Modeling Techniques

Modeling Source Code

To model a system's source code

• Either by forward or reverse engineering, identify the set of source code files of
interest and model them as components stereotyped as files.
• For larger systems, use packages to show groups of source code files.

• Consider exposing a tagged value indicating such information as the version number
of the source code file, its author, and the date it was last changed. Use tools to
manage the value of this tag.

• Model the compilation dependencies among these files using dependencies. Again,
use tools to help generate and manage these dependencies.

• For example, below figure shows five source code files. signal.h is a header file.
Three of its versions are shown, tracing from new versions back to their older
ancestors. Each variant of this source code file is rendered with a tagged value
exposing its version number.

Fig: Modeling Source Code

Modeling an Executable Release

To model an executable release

• Identify the set of components you'd like to model. Typically, this will involve some
or all the components that live on one node, or the distribution of these sets of
components across all the nodes in the system.

• Consider the stereotype of each component in this set. For most systems, you'll find a
small number of different kinds of components (such as executables, libraries, tables,
files, and documents). You can use the UML's extensibility mechanisms to provide
visual cues for these stereotypes.

• For each component in this set, consider its relationship to its neighbors. Most often,
this will involve interfaces that are exported (realized) by certain components and
 then imported (used) by others. If you want to expose the seams in your system,
model these interfaces explicitly. If you want your model at a higher level of
abstraction, elide these relationships by showing only dependencies among the
components.

• For example, below figure models part of the executable release for an autonomous
robot. This figure focuses on the deployment components associated with the robot's
driving and calculation functions. You'll find one component (driver.dll) that exports
an interface (IDrive) that is, in turn, imported by another component (path.dll).
driver.dll exports one other interface (ISelfTest) that is probably used by other
components in the system, although they are not shown here. There's one other
component shown in this diagram (collision.dll), and it, too, exports a set of
interfaces, although these details are elided: path.dll is shown with a dependency
directly to collision.dll.

Fig: Modeling an Executable Release

Modeling a Physical Database

To model a physical database

• Identify the classes in your model that represent your logical database schema.

• Select a strategy for mapping these classes to tables. You will also want to consider
the physical distribution of your databases. Your mapping strategy will be affected
by the location in which you want your data to live on your deployed system.

• To visualize, specify, construct, and document your mapping, create a component

diagram that contains components stereotyped as tables.

• Where possible, use tools to help you transform your logical design into a physical
design.

• Below figure shows a set of database tables drawn from an information system for a
school. You will find one database (school.db, rendered as a component stereotyped
as database) that's composed of five tables: student, class, instructor, department, and
course (rendered as a component stereotyped as table, one of the UML's standard
elements). In the corresponding logical database schema, there was no inheritance, so
mapping to this physical database design is straightforward.
 Fig: Modeling a Physical Database

Modeling Adaptable Systems

To model an adaptable system

• Consider the physical distribution of the components that may migrate from node to
node.

• You can specify the location of a component instance by marking it with a location
tagged value, which you can then render in a component diagram (although,
technically speaking, a diagram that contains only instances is an object diagram).

• If you want to model the actions that cause a component to migrate, create a
corresponding interaction diagram that contains component instances.

• You can illustrate a change of location by drawing the same instance more than once,
but with different values for its location tagged value.

• For example, below figure models the replication of the database from the previous
figure. We show two instances of the component school.db. Both instances are
anonymous, and both have a different value for their location tagged value. There's
also a note, which explicitly specifies which instance replicates the other.

Fig: Modeling Adaptable Systems

Forward and Reverse Engineering: The creation of code from a model

To forward engineer a component diagram

• For each component, identify the classes or collaborations that the component
implements.

• Choose the target for each component. Your choice is basically between source code
(a form that can be manipulated by development tools) or a binary library or
executable (a form that can be dropped into a running system).

• Use tools to forward engineer your models.

Reverse engineering (the creation of a model from code) a component diagram is not a
perfect process because there is always a loss of information.

To reverse engineer a component diagram

• Choose the target you want to reverse engineer. Source code can be reverse
engineered to components and then classes. Binary libraries can be reverse
engineered to uncover their interfaces. Executables can be reverse engineered the
least.

• Using a tool, point to the code you'd like to reverse engineer. Use your tool to
generate a new model or to modify an existing one that was previously forward
engineered.

• 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 following
relationships or neighboring components. Expose or hide the details of the contents
of this component diagram as necessary to communicate your intent.

• For example, below figure provides a component diagram that represents the reverse
engineering of the ActiveX component vbrun.dll. As the figure shows, the
component realizes 11 interfaces. Given this diagram, you can begin to understand
the semantics of the component by next exploring the details of its interfaces.

Fig: Reverse Engineering

Deployment Diagrams

• Deployment diagrams are one of the two kinds of diagrams used in modeling the
physical aspects of an object-oriented system.
• A deployment diagram shows the configuration of run time processing nodes and the
components that live on them.
• You use deployment diagrams to model the static deployment view of a system.
• For the most part, this involves modeling the topology of the hardware on which your
system executes.
• Deployment diagrams are essentially class diagrams that focus on a system's nodes.
• Deployment diagrams are not only important for visualizing, specifying, and
documenting embedded, client/server, and distributed systems, but also for managing
executable systems through forward and reverse engineering.

• With the UML, you use deployment diagrams to visualize the static aspect of these
physical nodes and their relationships and to specify their details for construction, as
in below figure.

Fig: A Deployment Diagram

Terms and Concepts

• A deployment diagram is a diagram that shows the configuration of run time

processing nodes and the components that live on them.
• Graphically, a deployment diagram is a collection of vertices and arcs.
Common Properties

A deployment diagram is just a special kind of diagram and shares the same common
properties as all other diagrams a name and graphical contents that are a projection into a
model. What distinguishes a deployment diagram from all other kinds of diagrams is its
particular content.

Contents

Deployment diagrams commonly contain

• Nodes
• Dependency and association relationships
• Like all other diagrams, deployment diagrams may contain notes and
constraints.
• Deployment diagrams may also contain components, each of which must
live on some node.
• Deployment diagrams may also contain packages or subsystems,

Common Uses

When you model the static deployment view of a system, you'll typically use deployment
diagrams in one of three ways.

1. To model embedded systems

• An embedded system is a software-intensive collection of hardware that interfaces
with the physical 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 temperature changes.
• You can use deployment diagrams to model the devices and processors that comprise
an embedded system.

2. To model client/server systems

• A client/server system is a common architecture focused on making a clear
separation of concerns between the system's user interface (which lives on the client)
and the system's persistent data (which lives on the server).
• Client/ server systems are one end of the continuum of distributed systems and
require you to make decisions about the network connectivity of clients to servers
and about the physical distribution of your system's software components across the
nodes.
• You can model the topology of such systems by using deployment diagrams.

3. To model fully distributed systems

• At the other end of the continuum of distributed systems are those that are widely, if
not globally, distributed, typically encompassing multiple levels of servers
• Such systems are often hosts to multiple versions of software components, some of
which may even migrate from node to node.
• Crafting such systems requires you to make decisions that enable the continuous
change in the system's topology. You can use deployment diagrams to visualize the
 system's current topology and distribution of components to reason about the impact
of changes on that topology.

Common Modeling Techniques

Modeling an Embedded System

To model an embedded system

• Identify the devices and nodes that are unique to your system.
• Provide visual cues, especially for unusual devices, by using the UML's extensibility
mechanisms to define system-specific stereotypes with appropriate icons. At the very
least, you'll want to distinguish processors (which contain software components) and
devices (which, at that level of abstraction, don't directly contain software).
• Model the relationships among these processors and devices in a deployment
diagram. Similarly, specify the relationship between the components in your system's
implementation view and the nodes in your system's deployment view.
• As necessary, expand on any intelligent devices by modeling their structure with a
more detailed deployment diagram.
• For example, below figure shows the hardware for a simple autonomous robot. You'll
find one node (Pentium motherboard) stereotyped as a processor.

Fig: Modeling an Embedded System

Modeling a Client/Server System

To model a client/server system

• Identify the nodes that represent your system's client and server processors.

• Highlight those devices that are germane to the behavior of your system. For
example, you'll want to model special devices, such as credit card readers, badge
readers, and display devices other than monitors, because their placement in the
system's hardware topology are likely to be architecturally significant.

• Provide visual cues for these processors and devices via stereotyping.
• Model the topology of these nodes in a deployment diagram. Similarly, specify the
relationship between the components in your system's implementation view and the
nodes in your system's deployment view.

• For example, below figure shows the topology of a human resources system, which
follows a classical client/server architecture. This figure illustrates the client/server
split explicitly by using the packages named client and server. The client package
contains two nodes (console and kiosk), both of which are stereotyped and are
visually distinguishable. The server package contains two kinds of nodes (caching
server and server), and both of these have been adorned with some of the components
that reside on each. Note also that caching server and server are marked with explicit
multiplicities, specifying how many instances of each are expected in a particular
deployed configuration. For example, this diagram indicates that there may be two or
more caching servers in any deployed instance of the system.

Fig: Modeling a Client/Server System

Modeling a Fully Distributed System

To model a fully distributed system

• Identify the system's devices and processors as for simpler client/server systems.

• If you need to reason about the performance of the system's network or the impact of
changes to the network, be sure to model these communication devices to the level of
detail sufficient to make these assessments.

• Pay close attention to logical groupings of nodes, which you can specify by using
packages.

• Model these devices and processors using deployment diagrams. Where possible, use
tools that discover the topology of your system by walking your system's network.

• If you need to focus on the dynamics of your system, introduce use case diagrams to
specify the kinds of behavior you are interested in, and expand on these use cases
with interaction diagrams.

• Below figure shows the topology of a fully distributed system. This particular
deployment diagram is also an object diagram, for it contains only instances. You can
see three consoles (anonymous instances of the stereotyped node console), which are
 linked to the Internet (clearly a singleton node). In turn, there are three instances of
regional servers, which serve as front ends of country servers, only one of which is
shown. As the note indicates, country servers are connected to one another, but their
relationships are not shown in this diagram.

Fig: Modeling a Fully Distributed System

Forward and Reverse Engineering

• There's only a modest amount of forward engineering (the creation of code from
models) that you can do with deployment diagrams.
• For example, after specifying the physical distribution of components across the
nodes in a deployment diagram, it is possible to use tools that then push these
components out to the real world. For system administrators, using the UML in this
way helps you visualize what can be a very complicated task.

Reverse engineering (the creation of models from code) from the real world back to
deployment diagrams is of tremendous value, especially for fully distributed systems that
are under constant change.
• You'll want to supply a set of stereotyped nodes that speak the language of your
system's network administrators, in order to tailor the UML to their domain. The
advantage of using the UML is that it offers a standard language that addresses
not only their needs, but the needs of your project's software developers, as well.

To reverse engineer a deployment diagram

• Choose the target that you want to reverse engineer. In some cases, you'll want to
sweep across your entire network; in others, you can limit your search.

• Choose also the fidelity of your reverse engineering. In some cases, it's sufficient to
reverse engineer just to the level of all the system's processors; in others, you'll want
to reverse engineer the system's networking peripherals, as well.

• Use a tool that walks across your system, discovering its hardware topology. Record
that topology in a deployment model.
• Along the way, you can use similar tools to discover the components that live on
each node, which you can also record in a deployment model. You'll want to use an
intelligent search, for even a basic personal computer can contain gigabytes of
components, many of which may not be relevant to your system.

• Using your modeling tools, create a deployment diagram by querying the model.

• For example, you might start with visualizing the basic client/server topology, then
expand on the diagram by populating certain nodes with components of interest that
live on them. Expose or hide the details of the contents of this deployment diagram as
necessary to communicate your intent.
UNIT - VI
Case Study: The Unified Library application, ATM application.

UNIT - VI

The Unified Library application

Introduction
Unified Library Application System emphasizes on the online reservation,
issue and return of books. This system globalizes the present library system. Using this
application the member can reserve any book from anywhere in the world. Still in
nascent stages, this application soon revolutionizes present library system.

Let us just have an overview of the unified library application system:

• Librarian lends books and magazines
• Librarian maintains the list of all the members of library
• Borrower makes reservation online
• Borrower can remove reservation online
• Librarian issues books to the borrower
• Librarian calculates dues to be paid by the borrower
• Borrower issues/returns books and/or magazines
• Librarian places order about the requirements to the master librarian
• Librarian updates system
• Master librarian maintains librarians

Textual Analysis
(a) Actors
i. Librarian
ii. Borrower
iii. Catalog
iv. Master Librarian
(b) Verbs
i. Borrower:
1. Logs into the system
2. Browses/searches for books or magazines
3. Makes/removes reservation
 4. Views results and reports from the unified library application system
ii. Librarian:
1. Manages and validates members
2. View reports from the system
3. Issues books
4. Calculates dues
5. Takes books
6. Places orders to the master librarian
7. Maintains list of books and magazine
iii. Master Librarian
1. Maintains other librarians
USECASE DIAGRAM:

Use case diagram is created to visualize the interaction of our system with the
outside world. The components of use case diagram are:
Use Case: Scenarios of the system
Actor: Someone or something who is interacting with the system
Relationship: Semantic link between use case and actor.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

ACTIVITY DIAGRAM:

Activity diagram shows the flow of events within our system.

The components are:
a) Start State
b) End State
c) Transition
d) Decision Box
e) Synchronization Bar
f) Swim Lane
INTERACTION DIAGRAM:

An interaction diagram models the dynamic aspects of the system by showing

the relationship among the objects and messages they may dispatch. There are two
types of interaction diagrams:

SEQUENCE DIAGRAM:
Sequence diagram shows the step to step what mush happen to accomplish a
piece of functionality provided by the system. The components are:
a) Actor
b) Object
c) Messages
d) Lifeline
e) Focus of Control
COLLABORATION DIAGRAM:
Collaboration diagram displays object interactions organized around objects and their
links to one another. The components are:
a) Actor
b) Object
c) Link

CLASS DIAGRAM:

Class diagram shows structure of the software system. The class diagram shows a
set of classes, interfaces and their relationships. The components are:
a) Class
b) Relationship:
The forms of relationship are:
1. Association
2. Aggregation
3. Generalization
4. Composition
5. Dependency
STATE CHART DIAGRAM:
State chart diagram show a life cycle of a single class. The state is a condition
where the object may be in. The components are:
a) Start state
b) End state
c) State
d) Transition
Member: Librarian:

Library Administrator:

ATM application
Introduction:
ATM system needs enhancement to record card information electronically is
automatically displays the details in the card. The ATM will communicate with the bank
computer over an appropriate communication link. The ATM will serve one customer at
a time. A customer will be required to insert an ATM card and enter a PIN number both
of which will be sent to bank for valuation as a part of each transaction. The customer
will then be able to perform one or more transactions. The card will be retained in the
machine until the customer indicates that he/she desires no further transactions, at which
point it will be returned.

Objective:
The main objective of the ATM system is to facilitate the user with easy
transaction of money at a faster rate. The ATM application will run automatically and
there will be no need of any manual interventions. Some built in functions are provided
which performs the depository with-drawl functions.

Scope:
The scope of the project of the ATM system is to understand the working of the
system and also to provide more security to the user as it facilitates with easy transaction.

Problem Statement :
The operations on the function of the ATM are as follows:
1. The card has to be inserted in the place of the provided.
2. As the system accepts the card it displays the name and other details of the user.
3. It asks for the password, which is exclusively assigned for the particular card.
4. If the code is correct then the system gets activated with details.

Withdraw usecase diagram :-

+sselecting cash

+mode of payment

+Enter Amount

+User asked for amount +selecting

Controller ATM
User

Withdraw cash usecase diagram :-

ATM Database
user
Withdraw sequence diagram :-

user controller ATM

1: user is used for amount

2: enter the amount

3: user is provided with various modes of payments

4: select modes of payments

5: selecting cash( )

sequence
diagram

6: selecting cheque( )

sequence
diagram

Withdraw cash sequence diagram :-

user ATM database

 Withdraw collaboration:-

2: enter the amount 4: select mode of payment

user controller

1: user is asked for amount

3: user is provided with various modes of payment

5: selecting cash

6: selecting cheque

ATM

Withdraw cash collaboration :-

user

1: cash is provided from the system

2: updating database
ATM database

Withdraw class diagram :-

Withdraw cash class diagram:-

State Transition diagram :

start login valid user

logged on

invalid login
relogin transition

withdrawl

logout updation
transaction completed

stop
Component Diagram: -

Login local
Controller bank

Login user

account
info and

Perform Transaction
Transaction Manager

Deployment Diagram:-

Activity diagram:-