Lab#2

Lab # 2
LAB # 2
AVM: Development View and Physical View
OBJECTIVE
OO modelling using Physical View Model and Development View Model.
THEORY:
1. Development or Module View Model:
The development view derives from the logical view and describes the static organization of the
system modules. Modules such as namespaces, class library, subsystem, or packages are building
blocks that group classes for further development and implementation. The software is packaged
and partitioned into small units such as program libraries or subsystems created by many teams of
developers. Each package has its own visibility and accessibility as package or default scope
visibility.
The development view maps software component elements to actual physical directories and files.
UML diagrams such as package diagrams and component diagrams are often used to support this
view. The stakeholders of this view can be programmers and software project managers.
i. Package Diagram:
A package is represented by a tabbed folder that indicates all included classes and sub-packages
reside. Packages play a similar role as a directory for grouping files in a file system; they allow
the organization of all closely related classes in one “container.”
For example, namespaces in .NET and packages in Java provide well-formed structures for
class accessibility and class correlations. We can organize functionally related classes in the
same package so that these classes can access each other within a default accessibility or
visibility. We can also organize related packages in a same parent package to build a class and
package hierarchy just like .NET class library and Java API. Another reason for using the
package organization is namespace sharing is that all classes in the same package have a unique
name but they may have the same name in different packages (namespaces).
A package diagram shows the dependency relationship between packages in which a change
of one package may result in changes in other packages. The package diagram may also specify
the contents of a package, i.e., the classes that constitute a package and their relationships. The
use of package diagrams to represent system structures can help reduce the dependency
complexity and simplify relationships among groups of classes.
SWE-208: Software Design and Architecture

Lab # 2
Fig1: Package Diagram
2. Physical View Model:
The physical view describes installation, configuration, and deployment of the software
application. It concerns itself with how to deliver the deployable system. The physical view shows
the mapping of software onto hardware. It is particularly of interest in distributed or parallel
systems. The components are hardware entities (processors), and the links are communication
pathways; together these specify how the various elements such as communication protocols and
middleware servers found in the logical, process, and development views are mapped onto the
various nodes in the runtime environment.
i. Component Diagram:
Component diagrams provide a simplified, high-order view of a large system. Classifying groups
of classes into components supports the interchangeability and reuse of code. The main purpose
of a component diagram is to show the structural relationships between the components of a
system. In UML, Components are made up of software objects that have been classified to serve
a similar purpose. Components are considered autonomous, encapsulated units within a system or
subsystem that provide one or more interfaces. By classifying a group of classes as a component
the entire system becomes more modular as components may be interchanged and reused.
Component diagrams document the encapsulation of the component and the means by which the
component interacts via interfaces.

Lab # 2
Fig3: Component diagram
Notations:
Component: A component can be represented as just a rectangle with the component's name and
the component stereotype text and/or icon. The component stereotype's text is "<<component>>"
and the component stereotype icon is a rectangle with two smaller rectangles protruding on its
left side.
Interface:
Provided interface symbols with a complete circle at their end represent an interface that the
component provides.

Lab # 2
Required interface symbols with only a half circle at their end (a.k.a. sockets) represent an
interface that the component requires (in both cases, the interface's name is placed near the
interface symbol itself).
ii. Deployment Diagram:
A deployment diagram depicts the physical configuration of the software system deployed on
hardware server nodes and the network between the nodes (defined as protocols). This diagram is
generated in the later phase of the software development life cycle. All components in the system
must be deployed on servers to provide services via network protocols. Component diagrams are
the basis for deployment diagrams.
Fig2: Deployment diagram
This example shows a basic deployment diagram for a website. There is a web server, a database
server, and the machine where the user views the website.
Notations:
Nodes:

Lab # 2
There are two types of nodes in a deployment diagram: device nodes and execution environment
nodes. Device nodes are computing resources with processing capabilities and the ability to
execute programs. Some examples of device nodes include PCs, laptops, and mobile phones.
An execution environment node, or EEN, is any computer system that resides within a device
node. It could be an operating system, a JVM, or another servlet container.
• Communication path: A straight line that represents communication between two device
nodes.
• Artifacts: A box with the header ">" and then the name of the file.
Exercise
Suppose you are working on a digital learning platform. The application consists of many
components like attendance, content management, online assessment, video conferencing etc.
a) Draw the component diagram showing the interaction of components via interfaces.
b) All components in the system must be deployed on servers to provide services via
network protocols. Draw the deployment diagram for the above mentioned application.

Lab#2

Uploaded by

Copyright:

Available Formats

Lab#2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lab#2

Uploaded by

Copyright:

Available Formats

Lab # 2

AVM: Development View and Physical View

SWE-208: Software Design and Architecture

Fig1: Package Diagram

2. Physical View Model:

SWE-208: Software Design and Architecture

Fig3: Component diagram

SWE-208: Software Design and Architecture

ii. Deployment Diagram:

Fig2: Deployment diagram

SWE-208: Software Design and Architecture

SWE-208: Software Design and Architecture

You might also like