IV.

Architectural Modeling
• Support for modeling Architecture in UML: (4+1 View Architecture of
UML / 5 Interlocking Views of UML):

Prepared By:Mr.Atul.B.Chaudhari
 Package
• A package is a general purpose mechanism for
organizing elements into groups.

Prepared By:Mr.Atul.B.Chaudhari
 Package Name
• Every package must have a name that distinguishes it from
other packages. A name is a textual string. That name alone is
known as a simple name; a path name is the package name
prefixed by the name of the package in which that package
lives, if any.

Prepared By:Mr.Atul.B.Chaudhari
 Owned Elements
• A package may own other elements, including classes,
interfaces, components, nodes, collaborations, use cases,
diagrams, and even other packages.
• Owning is a composite relationship, which means that the
element is declared in the package. If the package is destroyed,
the element is destroyed.
• Every element is uniquely owned by exactly one package.

• You can't have two classes named Queue owned by the same
package, but you can have a class named Queue in package P1
and another (and different) class named Queue in package P2.
The classes P1::Queue and P2::Queue are, in fact, different
classes and can be distinguished by their path names.
Prepared By:Mr.Atul.B.Chaudhari
Owned element and visibility

Prepared By:Mr.Atul.B.Chaudhari
 Importing and Exporting
• if A‘s package imports B's package, A can now see B,
although B cannot see A.
• Importing grants a one-way permission for the
elements in one package to access the elements in
another package.
• In the UML, you model an import relationship as a
dependency adorned with the stereotype import.
• The public parts of a package are called its
exports.
Prepared By:Mr.Atul.B.Chaudhari
Prepared By:Mr.Atul.B.Chaudhari
 Generalization
• generalizations, used to specify families of
packages.

Prepared By:Mr.Atul.B.Chaudhari
 Common Modeling Techniques
• 1. Modeling Groups of Elements: (Steps)
• Scan the modeling elements in a particular architectural view
and look for clumps defined by elements that are
conceptually or semantically close to one another.
• Surround each of these clumps in a package.
• For each package, distinguish which elements should be
accessible outside the package. Mark them public, and all
others protected or private.
• Explicitly connect packages that build on others via import
dependencies.
• In the case of families of packages, connect specialized
packages to their more general part via generalizations.

Prepared By:Mr.Atul.B.Chaudhari
Prepared By:Mr.Atul.B.Chaudhari
• 2. Modeling Architectural Views : (Steps)
• Identify the set of architectural views that are significant in
the context of your problem. In practice, this typically
includes a design view, a process view, an implementation
view, a deployment view, and a use case view.
• Place the elements (and diagrams) that are necessary and
sufficient to visualize, specify, construct, and document the
semantics of each view into the appropriate package.
• As necessary, further group these elements into their own
packages.
• There will typically be dependencies across the elements in
different views. So, in general, let each view at the top of a
system be open to all others at that level.

Prepared By:Mr.Atul.B.Chaudhari
Prepared By:Mr.Atul.B.Chaudhari
 Component Diagram
• Components: a component is a physical and
replaceable part o f a system that conforms to and
provides the realization of a set of interfaces.
• Graphically, a component is rendered as a rectangle
with tabs.
• Components are used to model the physical things
that may reside on node, such as executable,
libraries, tables, files and documents.

Prepared By:Mr.Atul.B.Chaudhari
 Name
• 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

Prepared By:Mr.Atul.B.Chaudhari
 Components and Classes
• Similarities : Both have names; both may realize a set of
interfaces; both may participate in dependency,
generalization, and association relationships;

• Differences:
• 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.
Prepared By:Mr.Atul.B.Chaudhari
Components and Classes

Prepared By:Mr.Atul.B.Chaudhari
Components and Interfaces

Prepared By:Mr.Atul.B.Chaudhari
 Kinds of Components
• 1. deployment components.: These are the
components necessary and sufficient to form an executable
system, such as dynamic libraries (DLLs) and executables
(EXEs).
• 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.: such as a COM+

Prepared By:Mr.Atul.B.Chaudhari
 Standard Elements
• The UML defines five standard stereotypes
that apply to components:

Prepared By:Mr.Atul.B.Chaudhari
 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.

Prepared By:Mr.Atul.B.Chaudhari
• 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

• Contents: Component diagrams commonly contain

Prepared By:Mr.Atul.B.Chaudhari
 Common Modeling Techniques
• 1. Modeling Source Code :
• identify the set of source code files 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.
• Model the compilation dependencies among these files using
dependencies.

Prepared By:Mr.Atul.B.Chaudhari
Prepared By:Mr.Atul.B.Chaudhari
• Modeling an Executable Release:
• Identify the set of components you'd like to model.
• Consider the stereotype of each component in this set. 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.

Prepared By:Mr.Atul.B.Chaudhari
• Modeling a Physical Database :
• Identify the classes in your model that represent your logical
database schema.
• Select a strategy for mapping these classes to tables.
• To visualize, specify, construct, and document your mapping,
create a component diagram that contains components
stereotyped as tables.

Prepared By:Mr.Atul.B.Chaudhari
• Modeling Adaptable Systems:
• Consider the physical distribution of the
components that may migrate from node to
node.

Prepared By:Mr.Atul.B.Chaudhari
 Deployment Diagram
• Node: 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.

Prepared By:Mr.Atul.B.Chaudhari
 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.

Prepared By:Mr.Atul.B.Chaudhari
 Nodes and Components
• Similarities: Both have names; both may participate in
dependency, generalization, and association relationships;
• Differences:
• 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; nodes represent the
physical deployment of components.

Prepared By:Mr.Atul.B.Chaudhari
Prepared By:Mr.Atul.B.Chaudhari
 Connections
• an association represents a physical connection
among nodes, such as an Ethernet connection, a
serial line, or a shared bus,

Prepared By:Mr.Atul.B.Chaudhari
 Deployment Diagrams
• 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.
• Contents:
– Nodes
– Connection
Prepared By:Mr.Atul.B.Chaudhari
 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
• you'll want to distinguish processors (which contain software
components) and devices
• Model the relationships among these processors and devices
in a deployment diagram.

Prepared By:Mr.Atul.B.Chaudhari
Prepared By:Mr.Atul.B.Chaudhari
• 2. Modeling a Client/Server System :
• Identify the nodes that represent your system's client and
server processors.
• Provide visual cues for these processors and devices via
stereotyping.
• Model the topology of these nodes in a deployment diagram.

Prepared By:Mr.Atul.B.Chaudhari
• 3. Modeling a Fully Distributed System:

Prepared By:Mr.Atul.B.Chaudhari