ARCHITECTURAL

MODELING
1.  Components
2.  Deployments
3.  Component diagrams
4.  Deployment diagrams
 COMPONENTS
• Important building blocks in modeling the
physical aspects of the system.
• A component is a physical and replaceable
part of a system.
• Used in modeling the physical things that
may reside on a node, such as executables,
libraries, tables, files and documents.
• A component physically represents the physical
packaging of logical elements such as classes,
interfaces, and collaborations.
• A component realizes a set of interfaces.
• Interfaces therefore bridge your logical and
physical models.
• You may specify an interface for a class in a
logical model and that same interface will carry
over to some physical component that realizes it.
• Ex: Object libraries, executables, COM +
components and EJB
• We can also use components to represent tables,
files and documents.
COM+ is an extension of Component Object Model
(COM), Microsoft's strategic building block
approach for developing application programs.
COM+ is both an object-oriented programming
architecture and a set of operating system services.
A DLL file, short for Dynamic Link Library, is a
type of file that contains instructions that other
programs can call upon to do certain things. This
way, multiple programs can share the abilities
programmed into a single file, and even do so
simultaneously.
Enterprise JavaBeans components. The
Enterprise JavaBeans (EJB) technology defines
a model for the development and deployment
of reusable Java server components, called EJB
components. An EJB component is a nonvisual
server component with methods that typically
provide business logic in distributed
application
Component Notation
Components and Classes:
In many ways components are like classes i.e.
• both have names.
• Both may realize a set of interfaces
• Both may participate in dependency, generalization, association,
relationships.
• Both may be nested
• Both may have instances.
• Both may be participants in interactions.
Differences between components and classes.
• classes represent logical abstractions ; components represent
physical things.
• components may live on nodes, classes may not.
• Classes may have attributes and operations directly, where as
components can not have attributes but can have operations
Relationship between the 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
component.
• we can show the relationship between a
component and its interfaces in one of two
ways.
1. most common style renders the interface in its
elided , iconic form.
2. rendering the interface in its expanded form
Export interface:An interface that a
component realizes is called export interface.
means the component provides it as a service
to other components.Example:Component.java
in the figure.

Import interface:-The interface that a

component uses is called import
interface.Example image.java
BINARY REPLACEABILITY:
• 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.

• The interfaces are key to making this happen.

   Component is physical.  It lives in the world of bits
not concepts.
   A component is replaceable.
  A component is a “part of a system”. A component
rarely stands alone like IC chip. It collaborates with
other components.
KINDS OF COMPONENTS :
3- kinds of components:
1. Deployment components: components necessary and
sufficient to form an executable system, such as
dynamic libraries(DLL) and executables(EXE).

2. Work product components: These components are

essentially the residue of the development process,
consisting of things such as source code files and data
files

3.  Execution Components: These are created as a

consequence of an executing system such as a COM+
object, which is instantiated from DLL.
ORGANIZING COMPONENTS:
• We can organize them into packages
* dependency
• generalization
• Association
• aggregation
• realization relationships
Standard Elements:
• All UML extensibility mechanisms(stereo types,
tagged values, constraints) apply to components.
• The UML defines five standard stereotypes that
apply to components:
1. Executable : Specifies the component that may be executed on
a node.
2.  Library: Specifies a static or dynamic object library.
3. Table: Specifies a component that represents a database table.
4.  File: Specifies a component that represents a document
containing source code or data.
5.  Document: Specifies a component that represents a document.
Uses of Components
1. Modeling Executables and Libraries

Render.dll realizes /exports some interfaces and animator.exe

uses.
• Figure shows a set of components drawn from
a personal productivity tool that runs on a
single personal computer.

• Figure includes one executable(animator.exe,

with tagged value noting its version number)
and four libraries(dlog.dll, wrfrme.dll,
render.dll and retrace.dll),
2.    Modeling Tables, Files, and documents
• When the implementation includes data files, help documents,
scripts, log files, initialization files and installations/removal files.
• In the figure the tables, files, and documents
that are part of the deployed system
surrounding the executable.“Animator.exe”.
• Figure includes one document (animator.hlp),
one simple file(animator.ini) and one database
table(shapes.tbl) all which use the UML’s
standard elements for documents, files and
tables, respectively.
 3. Modeling source code

Configuration of all the source code files that

your development tools use to create the
components
The figure shows the source code files that are used to build the
library render.dll
 2. DEPLOYMENT
NODE: It is a physical element that exists at
runtime and represents a computational resource.
• Generally nodes having at least some memory and often processing
capabilities.
• used to model the topology of the hardware on which our system
executes.
• It typically represents a processor or a device on which
components may be deployed.
• When you architect a software intensive system you have to
consider both its logical and physical dimensions.
• On Logical: We will find classes, interfaces, collaborations,
interaction, state machines.
• On Physical: We will find
components(which represents physical
packaging of logical elements) and
nodes(which represents hardware on which
there components are deployed and
executed).
• Node graphically represented as CUBE
• By using stereotypes we can tailor this node
notation to represent specific kind of
processors and devices.
•Name:- It is a textual string, the name alone
is called simple name;
• “A path name”
Common features
• In many ways, nodes are lot like components
both have names.
• Both may participate in dependency,
generalization, association relationships.
• Both may be nested.
• Both may have instances.
• Both may be participants in interactions.
Differences :
1.Components are things that participate in the
execution of a system
Nodes are the things that execute components.
2. Components represent the physical packaging
of logical elements
where as Nodes represent the physical
deployment of components.
Relationship between a Node and Component
Organizing Nodes:
• We organize nodes by grouping them in packages .
• We can also organize nodes by specifying dependency,
generalization, and association relationships among
them.
Connections:
• The most common type of relationship we use among
nodes is “ Association”.
• In the context of node, association represents a physical
connection among nodes, such as Ethernet connection, a
serial line shared buses
• We can even use associations to model indirect
connections, such as a “satellite link” between distant
processors.
• We can also include roles, multiplicity and
constraints in nodes.
Example to distinguish between a 10-T
Ethernet connection and RS –232 serial
connection we used stereotyped.
COMMON MODELING TECHNIQUES:
1.   Modeling Processors and Devices:
• Modeling the processors and devices that form
the topology of a stand-alone, embedded, client-
server or distributed system is the most common
use of nodes.
• Processor: It is a node that has the processing
capability, means it can execute a component.
• Device: It is a node that has no processing
capability and in general represent something
that interfaces to the real world.
The server is a node stereotypes as a generic processor;
the “kiosk” and the “console” are nodes stereotypes as
special kinds of processors and “RAID farm” is a node
stereotyped as a special kind of “device”.
2.  MODELLING DISTRIBUTION OF
COMPONENTS
• When we model the topology of a system it’s
often useful to visualize or specify the “Physical
distribution” of its components across the
processor and devices that make up the system.
•Below diagram is an object diagram of previous one, which
visualizes specific instances of each node.
•“RAID farm” and “kiosk” instance both anonymous and
other two instances are names (C: for the console and S: for
the server).
3. COMPONENT DIAGRAMS
• * These are first kind of diagrams found in modeling
the physical aspects of object-oriented systems.
• It shows the organization and dependencies among a
set of components.
• Used to model the static implementation view of a
system.
• It is essentially class diagrams that focus on system's
components.
• This involves the modeling the physical things that
reside on a node such as
executables,tables,libraries,files and documents
The diagram shows Components & their relationships

Component
Component Diagram
Diagram
 Captures
 Captures the
the physical
physical structure
structure of
of the
the
implementation
implementation
• Contents
Component diagrams commonly contain
• Components
• Interfaces
• Dependency, generalization, association,
realization relationships.
• It may contain notes and constraints,
packages, subsystems.
Common Uses:
• To model source code
• To model Executable releases
• To model physical databases
• To model adaptable systems
Modeling source code:the figure shows compilation
dependencies among source files.Render.h is used by
render.cpp,poly.h has compilation dependency to render.h
Modeling adaptable systems:In Adaptable systems,
a database is replicated across several nodes
Modeling physical database:The figure shows
that the database School.db is an Aggregation of five
other tables.
 Modeling an executable release
Below figure models part of the executable release for an autonomous robot. The
figure focuses on the deployment components associated with the robots driving
and calculation functions.
 DEPLOYMENT DIAGRAMS
• Shows the configuration of runtime processing
nodes and components live on them.
• used to model the static deployment view of a
system.
• Most part of this involves modeling the topology
of the hardware on which your system executes.
• It is essentially class diagrams that focus on a
system’s node.
DEPLOYMENT DIAGRAM
Contents of deployment diagrams
1.      Nodes
2.      Dependency and association relationships

• It may contain notes and constraints. May also

contain components, each of which must live on
some node.
• It may also contain packages or subsystems, both
of which are used to group elements of our model
into large chunks.
 Common uses
 To model the embedded systems
 To model client server systems
To model fully distributed
systems
 figure below shows the hardware for a simple autonomous robot.
-   one node(Pentium mother board) stereotyped as a processor.
Surrounding this node are eight devices, each stereotyped as a device
and rendered with an icon that offers a clear visual cue to its real world
equivalent.

Modeling
Embedded
system
2. To model client- server systems:
• Deployment diagrams can also be used to
document your decisions about the topology of
your client server system and how it’s s/w
components are distributed across the client
aand the server.
This diagram indicates that there may be two or more “
catching servers” in any deployed instance of the system.

It is a topology of a human resource system.the nodes are grouped into clients and servers.
3.   To model fully distributed systems
• Globally distributed, typically encompassing
multiple level servers, in this, often hosts to
multiple versions of software components, some
of which may migrate from node to node.
Crafting these type of systems require you to
make decisions that enable the continuous
change in the system’s topology.
• We can use the deployment diagram to visualize
the system’s current topology and distribution of
components to reason about the impact of change
in topology.
 
THANK YOU