Component and

Deployment DIAGRAMS
 Component and Deployment
Diagrmas

A component is a code module.

•

Component diagrams are physical analogs

•

of class diagram.

Deployment diagrams show the physical

•

configurations of software and hardware.

Sample Component and
Deployment Diagrams
PACKAGE,
COMPONENT,
DEPLOYMENT
DIAGRAMS IN UML
 Packages
5
Package — general-purpose mechanism for organizing elements into groups.
• Nested Elements: Composite relationship (When the whole dies, its
parts die as well, but not necessarily vice versa)
• (C++ namespace; specialization means “derived”)

simple names path names

Client Client
visibility
+ OrderForm +OrderForm -Order enclosing package name
Business rules + TrackingForm package name
- Order Client
+TrackingForm
Sensors::Vision
textual nesting graphical nesting { version = 2.24 }

• Packages that are friends to another may see all the elements of that
Visibility package, no matter what their visibility.
• If an element is visible within a package, it is visible within all packages
nested inside the package.
Dependency –Among Packages
 Two Stereotypes of Dependency Among Packages:
 access: the source package is granted the right to reference the
elements of the target package (:: convention)
 import: a kind of access; the public contents of the target package
enter the flat namespace of the source as if they had been declared in the
source

Client
packageName + OrderForm
+ TrackingForm
- Order
<<import>> <<access>>
exports Policies <<import>>

packageName packageName
+OrderRules
-GUI:Window imports
subPackageName PackageClass GUI
<<import>>
+Window
+Form
#EventHandler

6
 Modeling Groups of Elements
 Look for “clumps” of elements that are semantically close to one another.
 Surround “clumps” with a package.
7
 Identify public elements of each package.
 Identify import dependencies.

Use Case package Diagram

• Included and extending use cases belong in the same
package as the parent/base use case
Java.awt • Cohesive, and goal-oriented packaging
• Actors could be inside or outside each package
utd.administration

registration

Tools.db

db interfaces

Cloudscape Oracle
 Class Package Diagrams
(http://www.agilemodeling.com/artifacts/packageDiagram.htm)

 Classes related through inheritance, composition or

communication often belong in the same package
Schedule
<<import>>

Seminar
Registration <<import>>Java
<<application>> Student Contact Infrastructure
Point <<technical>>
<<import>>
<<import>>
Professor <<import>>

• A frame depicts the contents of a package (or components, classes, operations,

etc.)
• Heading: rectangle with a cut-off bottom-right corner, [kind] name [parameter]
Package Schedule
1..* 1 A frame encapsulates
Seminar Course a collection of collaborating instances or
refers to another representation of such
1 1..* held at
0..* 1
Location 8
Enrollment Time
 9

COMMON MECHANISMS
•Adornments
Notes & Compartments
•Extensibility Mechanisms
–Stereotypes - Extension of the UML metaclasses.
–Tagged Values - Extension of the properties of a UML element.
–Constraints - Extension of the semantics of a UML element.
 Adornments
 Textual or graphical items added to an element’s basic notation.

 Notes - Graphical symbol for rendering constraints or comments attached

to an element or collection of elements; No Semantic Impact
Rendered as a
rectangle with a dog- See smartCard.doc for See http://www.rational.com
details about this for related info.
eared corner.
routine.
May contain combination of May contain URLs linking
text and graphics. to external documents.

Additional Adornments Transaction

• Placed near the element as named addAction()
– Text compartment
Exceptions
– Graphic Resource Locked
• Special compartments for adornments in
– Classes Client
– Components anonymous bill.exe
– Nodes compartment report.exe
10
contacts.exe
 Stereotypes
11
• Mechanisms for extending the UML vocabulary.
• Allows for new modeling building blocks or parts.
 Allow controlled extension of metamodel classes. [
UML11_Metamodel_Diagrams.pdf]

 Graphically rendered as «metaclass»

ModelElement
 Name enclosed in guillemets (<< >> )
 <<stereotype>>
 New icon
Internet

• The new building block can have

• its own special properties through a set of tagged values
• its own semantics through constraints
 Tagged Values
12
• a (name, value) pair describes a property of a model
element.
• Properties allow the extension of “metamodel” element
attributes.
• modifies the semantics of the element to which it relates.
• Rendered as a text string enclosed in braces { }
• Placed below the name of another element.

<<library>> «subsystem»
Server accounts.dll AccountsPayable
{ dueDate = 12/30/2002
{channels = 3} {customerOnly} status = unpaid }

tagged values
 Constraints
• Extension of the semantics of a UML element.
13• Allows new or modified rules
• Rendered in braces {}.
– Informally as free-form text, or
– Formally in UML’s Object Constraint Language (OCL):
E.g., {self.wife.gender = female and self.husband.gender = male}

Corporation
Portfolio Department
BankAccount * *
{or}
{secure} {subset}
Person
BankAccount id : {SSN, passport} member1..* 1 manager
A simple constraint Constraint across multiple elements Person

Person employees employers Company

age: Integer
0..* 0..*
Company
self.employees.forAll(Person p |
p.age >= 18 and p.age <= 65)
Component diagram
UML component diagrams shows
 the dependencies among software

components,
 including the classifiers that specify

them (for example implementation

classes) and
 the artifacts that implement them; such

as source code files, binary code files,

executable files, scripts and tables.
Component diagram
 Component DiagramUML1.x – implementation view
 Shows a set of components and their relationships.
16
 Represents the static implementation view of a system.
 Components map to one or more classes, interfaces, or collaborations.

Mapping of Components into Classes Components and their Relationships

loanOfficer.dll component
Registrar.exe

LoanOfficer CreditSearch
Course.dll
Student.dll
LoanPolicy
classes
Component
UML2.0 – architectural view
Diagram
17
Big demand, hmm…
 Short history behind architecture
 Architecture still an emerging discipline
 Challenges, a bumpy road ahead

 UML and architecture evolving in parallel

 Component diagram in need of better
formalization and experimentation
 Component Diagram – another example
(www.cs.tut.fi/tapahtumat/olio2004/richardson.pdf)

18
Component Diagram – another example
(www.cs.tut.fi/tapahtumat/olio2004/richardson.pdf)

19
 Component Diagram – another example
(www.cs.tut.fi/tapahtumat/olio2004/richardson.pdf)

20
Component
UML2.0 – architectural view
Diagram
Explicit description of interfaces: lollipop

21 provided services to other components Component

requested services from other components
socket

An interface is a collection of 1..* methods, and 0..* attributes

Interfaces can consist of synchronous and / or asynchronous operations

A port (square) is an interaction point between the component and its environment.

Can be named; Can support uni-directional (either provide or require) or bi-directional (both provide and require) communicat
Can support multiple interfaces.

possibly concurrent interactions

fully isolate an object’s internals from its environment

caller or callee?

security AccessControl

StudentAdministration
Student Encription
Incoming
Incoming Persistence
signals/calls
signals/calls Outgoing
Outgoing
signals/calls
signals/calls
StudentSchedule DataAccess
Data[1..*]
Component Diagram: UML 1.x and UML 2.0
(http://www.agilemodeling.com/artifacts/componentDiagram.htm)

22
 Component Diagram: UML 1.x and
UML 2.0
(http://www.agilemodeling.com/artifacts/componentDiagram.htm)

23

So, how many different conventions for components in UML2.0?

 Building a Component

25

 simplified the ports to either provide or require a single interface

 relationships between ports and internal classes in three different ways:
i) as stereotyped delegates (flow), as delegates, and as realizes (logical->physical) relationships
Cohesive reuse and change of classes; acyclic component dependency ???
Component Diagram – Connector & Another
Example
 a connector: just a link between two or more connectable elements (e.g., ports or
interfaces)
 2 kinds of connectors: assembly and delegation. For “wiring”
 An assembly connector: a binding between a provided interface and a required

interface (or ports) that indicates that one component provides the services
required by another; simple line/ball-and-socket/lollipop-socket notation
 A delegation connector binds a component’s external behavior (as specified at

a port) to an internal realization of that behavior by one of its parts (provide-provide,

request-request).

delegation
delegation

assembly store
connector

Left delegation: direction of arrowhead indicates

“provides”
Right delegation:
26 direction of arrowhead indicates
So, what levels of abstractions for connections?
“requests”
 Structured Class
 A structured class(ifier) is defined, in whole or in part, in terms of a
number of parts - contained instances owned or referenced by the
structured class(ifier).
 With a similar meaning to a composition relationAny difference?
 A structured classifier’s parts are created within the containing classifier
(either when the structured classifier is created or later) and are destroyed
when the containing classifier is destroyed.
 Like classes and components, combine the descriptive capabilities of
structured classifiers with ports and interfaces

component or
class?

connector

label /roleName : type

Components extend classes with additional features such as


the ability to own more types of elements than classes can; e.g., packages,
constraints, use cases, and artifacts

deployment specifications that define the execution parameters of a component
27
deployed to a node
 Classifiers
 Classifier—mechanism that describes structural (e.g. class attributes)
28
and behavioral (e.g. class operations) features. In general, those
modeling elements that can have instances are called classifiers.
 cf. Packages and generalization relationships do not have instances.

an asynchronous stimulus
communicated between instances
class interface signal
Shape data type <<signal>>
IUnknown OffHook
origin
<<type>>
move() Int
resize() { values range from
display() -2**31 to +2**31 - 1 }
use case

Process loan
egb_server
membership_server
kernel32.dll
<<subsystem>>
Customer Service

component node
subsystem
Generalizable Element, Classifier, Class, Component?
 Structured Class – Another
Example
29

what kind?
Deployment diagram
UML deployment diagram depicts
 a static view of the run-time configuration

of hardware nodes and the software

components that run on those nodes.
 Deployment diagrams show

 the hardware for your system,

 the software that is installed on that

hardware,
 and the middleware used to connect the

disparate machines to one another.

Deployment diagram
Deployment diagram
 Deployment Diagram
33
• Shows a set of processing nodes and their relationships.
• Represents the static deployment view of an architecture.
• Nodes typically enclose one or more components.

TCP/IP IIS + PhP

Server
TCP/IP

J2EE Membership
Server Server
DecNet

Tomcat
Server
 Structural Diagrams - Deployment Diagram
(http://www.agilemodeling.com/artifacts/deploymentDiagram.htm)

34

Student administration application

Physical nodes - stereotype device
WebServer - physical device or
software artifact
RMI/message bus: connection type
Nodes can contain other nodes
or software artifacts recursively
 Deployment specs: configuration files:
name and properties
Structural Diagrams - Deployment
Diagram
(http://www.agilemodeling.com/artifacts/deploymentDiagram.htm)

35
Is this better?
More concrete
Implementation-oriented
37
Questions to Answer

Find out the classes and objects from the following real world problems:
1)Railway Reservation System
2)Hospital Management System

Consider a real world application such as Flipkart in “E Commerce

System”

Q1. Identify the key abstractions (classes) from it

Q2. Find out the type of hierarchy between the abstractions
Q3. Identify the functionalities which have polymorphic behavior in the
above system
 Contd..
In an “Online Vehicle Purchase System”, different types of vehicles can be
purchased online by the users. Initially, all the users are in a visitor category and
once they have registered with the website, they will be categorized as customers.
The customers can order a vehicle online, they will be issued a bill and they can
use their credit card or debit card for online payment. On successful completion of
payment process, they will be provided with gift coupons for next purchase.

Assuming that we have a collection of classes and objects present in this

requirement,

Think individually and identify the classes and prove that the type of relationship
between them will vary depending upon their properties given in object oriented
paradigm.