OOAD

UNIT-VI
Architectural Modelling
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
A component name must be unique within its enclosing package, 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 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.

Components and Classes

In many ways, 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.
However, there are some significant differences between components and classes.
1.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.
2.Components represent the physical packaging of otherwise logical components and are
at a different level of abstraction
3.Classes may have attributes and operations directly. In general, components only have
operations that are reachable only through their interfaces.

The first difference is the most important. When modeling a system, deciding if you should
use a class or a component involves a simple decision• if the thing you are modeling lives
directly on a node, use a component; otherwise, use a class.

Prepared by T. SIVA RAMA KRISHNA, M TECH 1

 OOAD
The second difference suggests a relationship between classes and components. In particular,
a component is the physical implementation of a set of other logical elements, such as classes
and collaborations. As Figure shows, the relationship between a component and the classes it
implements can be shown explicitly by using a dependency relationship.

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.

As 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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 2

 OOAD

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.

Binary Replaceability

The basic intent of every component-based operating system facility is to permit the
assembly of systems from binary replaceable parts. This means that you can create a system
out of components and then evolve that system by adding new components and replacing old
ones, without rebuilding the system. Interfaces are the key to making this happen. When you
specify an interface, you can drop into the executable system any component that conforms to
or provides that interface. You can extend the system by making the components provide new
services through other interfaces, which, in turn, other components can discover and use.
These semantics explain the intent behind the definition of components in the UML. A
component is a physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces.
First, a component is physical. It lives in the world of bits, not concepts.
Second, a component is replaceable. A component is substitutable• it is possible to replace a
component with another that conforms to the same interfaces.

Third, a component is part of a system.

Fourth, as discussed in the previous , a component conforms to and provides the realization
of a set of interfaces.

Prepared by T. SIVA RAMA KRISHNA, M TECH 3

 OOAD

Kinds of Components

Three kinds of components may be distinguished.

Deployment components: These are the components necessary and sufficient to form an
executable system, such as dynamic libraries (DLLs) and executables (EXEs).

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.

Execution components: These components are created as a result 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:

Prepared by T. SIVA RAMA KRISHNA, M TECH 4

 OOAD

Deployment
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,
Just as with classes, you may draw nodes adorned with tagged values or with additional
compartments to expose their details.

Nodes and Components.

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.

However, there are some significant differences between nodes and components.
1.Components are things that participate in the execution of a system; nodes are things
that execute components.

2.Components represent the physical packaging of otherwise logical elements; nodes

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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 5

 OOAD
The second difference suggests a relationship among classes, components, and nodes.

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 Figure shows. You can even use associations to
model indirect connections, such as a satellite link between distant processors.

Prepared by T. SIVA RAMA KRISHNA, M TECH 6

 OOAD
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.

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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 7

 OOAD
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

. You use component diagrams to represent 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.

Common Modeling Techniques

1.Modeling Source Code

.
Steps 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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 8

 OOAD

2.Modeling an Executable Release

Steps 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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 9

 OOAD
3.Modeling a Physical Database

1. For simple CRUD (create, read, update, delete) operations, implement them with
standard SQL or ODBC calls.

2. For more-complex behavior (such as business rules), map them to triggers or stored
procedures.

Given these general guidelines, 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.

4.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

Prepared by T. SIVA RAMA KRISHNA, M TECH 10

 OOAD
location by drawing the same instance more than once, but with different values for its
location tagged value.

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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 11

 OOAD
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

You use deployment diagrams to model the static deployment view of a system. This view
primarily addresses the distribution, delivery, and installation of the parts that make up the
physical system.

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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 12

 OOAD
Common Modeling Techniques

1.Modeling 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.

example, Figure shows the hardware for a simple autonomous robot. You'll find one
node (Pentium motherboard) stereotyped as a processor.

Prepared by T. SIVA RAMA KRISHNA, M TECH 13

 OOAD
2.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

therelationship between the components in your system's implementation view and the nodes
in your system's deployment view.

3.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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 14

 OOAD

Prepared by T. SIVA RAMA KRISHNA, M TECH 15