Architectural Modeling

Components:
 Components live in the material world of bits and therefore are an important building
block in modeling the physical aspects of a system.
 A component is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces.

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.

Components and Classes:

 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.
 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.
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.
 Component and its interfaces in one of two ways:
 The First 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.

Kinds of Components:
 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.
 Execution components: These components are created as a consequence of an
executing system, such as a COM+ object, which is instantiated from a DLL.
Standard Elements:
 Executable : Specifies a component that may be executed on a node
 Library : Specifies a static or dynamic object library
 Table : Specifies a component that represents a database table
  File : Specifies a component that represents a document containing source code or
data
 Document : Specifies a component that represents a document
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”.
 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 comprise of:
 Components
 Interfaces
 Relationships
 Packages and Subsystems (optional)

Component diagrams are used for:

 Constructing systems through forward and reverse engineering.
 Modeling configuration management of source code files while developing a system
using an object-oriented programming language.
 Representing schemas in modeling databases.
 Modeling behaviors of dynamic 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.

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.

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.

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.

Deployments:
Nodes, just like components, live in the material world and are an important building
block in modeling the physical aspects of a system. 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.
A node typically represents a processor or a device on which components may be
deployed.
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.
 Simple name: Name alone is known as a simple name.
 Path name: Node name prefixed by the name of the package in which that node lives.
Nodes and Components:
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 are things that participate in the execution of a system; nodes are things
that execute components.
The relationship between a node and the components it deploys can be shown
explicitly by using a dependency relationship.

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.
 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.
 Deployment diagrams 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 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.

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

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.