UNIT 4: ARCHITECTURAL MODELING-1

Components

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.

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.

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

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.
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. A component rarely stands alone. Rather, a given component
collaborates with other components and in so doing exists in the architectural or technology context in which it is
intended to be used.
Fourth, a component conforms to and provides the realization of a set of interfaces.

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).
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.
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:
1. executable: Specifies a 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.

Common Modeling Techniques:

Modeling Executables and Libraries:
To model executables and libraries:
1. Identify the partitioning of your physical system. Consider the impact of technical, configuration management,
and reuse issues.
2. 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.
3. If it's important for you to manage the seams in your system, model the significant interfaces that some
components use and others realize.
4. 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.

Modeling Tables, Files, and Documents:

To model tables, files, and documents:
1. Identify the ancillary components that are part of the physical implementation of your system.
2. Model these things as components. If your implementation introduces new kinds of artifacts, introduce a new
appropriate stereotype.
3. 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.
Modeling an API:
To model an API:
1. Identify the programmatic seams in your system and model each seam as an interface, collecting the attributes and
operations that form this edge.
2. 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.
3. Model the realization of each API only insofar as it is important to show the configuration of a specific
implementation.

Modeling Source Code:

To model source code:
1. 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.
2. 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.
3. 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.
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. 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.

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.

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.
Common Modeling Techniques:
Modeling Processors and Devices:
To model processors and devices:
1. Identify the computational elements of your system's deployment view and model each as a node.
2. 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.
3. As with class modeling, consider the attributes and operations that might apply to each node.

Modeling the Distribution of Components:

To model the distribution of components:
1. For each significant component in your system, allocate it to a given node.
2. 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.
3. 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.
Component Diagrams
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
1. Components
2. Interfaces
3. 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 Modeling Techniques:

Modeling Source Code:
To model a system's source code:
1. Either by forward or reverse engineering, identify the set of source code files of interest and model them as
components stereotyped as files.
2. For larger systems, use packages to show groups of source code files.
3. 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.
4. Model the compilation dependencies among these files using dependencies. Again, use tools to help generate and
manage these dependencies.

Modeling an Executable Release:

To model an executable release:
1.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.
2. 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.
3. 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.

Modeling a Physical Database:

A logical database schema captures the vocabulary of a system's persistent data, along with the semantics
of their relationships. Physically, these things are stored in a database for later retrieval, a relational database, an
object-oriented one, or a hybrid object/relational database. The UML is well suited to modeling physical databases,
as well as logical database schemas.
To model a physical database:
1. Identify the classes in your model that represent your logical database schema.
2. 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.
3. To visualize, specify, construct, and document your mapping, create a component diagram that contains
components stereotyped as tables.
4. Where possible, use tools to help you transform your logical design into a physical design.

Modeling Adaptable Systems:

To model an adaptable system:
1. 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).
2. 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.

Forward and Reverse Engineering:

To forward engineer a component diagram:
1. For each component, identify the classes or collaborations that the component implements.
2. 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).
3. Use tools to forward engineer your models.
To reverse engineer a component diagram
1. 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.
2. 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.
3. 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.
Deployment Diagrams

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
1. Nodes
2. 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, both of which are used to group elements of your model into larger chunks. Sometimes, you'll want to
place instances in your deployment diagrams, as well, especially when you want to visualize one instance of a
family of hardware topologies.

Common Modeling Techniques:

Modeling an Embedded System:
To model an embedded system:
1. Identify the devices and nodes that are unique to your system.
2. 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).
3. 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.
4. As necessary, expand on any intelligent devices by modeling their structure with a more detailed deployment
diagram.
Modeling a Client/Server System:
To model a client/server system:
1. Identify the nodes that represent your system's client and server processors.
2. 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.
3. Provide visual cues for these processors and devices via stereotyping.
4. 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.

Modeling a Fully Distributed System:

To model a fully distributed system:
1. Identify the system's devices and processors as for simpler client/server systems.
2. 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.
3. Pay close attention to logical groupings of nodes, which you can specify by using packages.
4. 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.
4. 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.
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.
To reverse engineer a deployment diagram:
1. 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.
2. 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.
3. Use a tool that walks across your system, discovering its hardware topology. Record that topology in a
deployment model.
4. 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.
4. 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.