UNIT 2
STATIC MODELING
1
1.
2.
3.
4.
5.
Class Diagrams
Object Diagrams
Component Diagrams
Deployment Diagrams
Package Diagrams
2
1. A classifier is a mechanism that describes
structural and behavioral features.
2. Classifiers include classes, interfaces,
datatypes, signals, components, nodes, use
cases, and subsystems.
3
Classifiers
4
CLASS DIAGRAM
• Books:
1. UML in a Nutshell by Dan Pilone
2. UML User Guide
3. UML 2 & the Unified Process by Jim Arlow
5
• Class diagrams are one of the most fundamental
diagram types in UML.
• They are used to capture the static relationships
of your software; in other words, how things are
put together
• A class represents a group of things that have
common state and behavior.
6
Class vs Objects
• Volkswagen, Toyota, and Ford are all cars, so
you can represent them using a class named
Car.
• Each specific type of car is an instance of that
class, or an object.
7
• UML suggests that the class name:
– Start with a capital letter
– Be centered in the top compartment
– Be written in a boldface font
8
• Typically you show the name of the object
followed by a colon followed by its type (i.e.,
class). You show that this is an instance of a class
by underlining the name and type
9
Attributes
• Inlined Attributes
10
Inlined Attributes
• You can list a class's attributes right in
rectangle notation; these are typically called
inlined attributes
11
1. Visibility
One of the most important details you can specify
for a classifier's attributes and operations.
The visibility of a feature specifies whether it can
be used by other classifiers.
In the UML, you can specify any of three levels of
visibility.
12
1. Public:
Any outside classifier with visibility to the given
classifier can use the feature;
specified by the symbol +
2. Protected
Any descendant of the classifier can use the feature;
specified by the symbol #
3. Private
Only the classifier itself can use the feature;
specified by the symbol 13
• When you specify the visibility of a classifier's
features, you generally want to hide all its
implementation details and expose only those
features that are necessary to carry out the
responsibilities of the abstraction.
• That's the very basis of information hiding, which
is essential to building solid, flexible systems.
• If you don't explicitly adorn a feature with a
visibility symbol, you can usually assume that it is
public.
14
Visibility
15
2. Derived Attribute
/
Indicates the attribute is derived.
A derived attribute is simply one that can be
computed from other attributes of the class.
16
3. name
• Is a noun or short phrase naming the
attribute. Typically the first letter is lowercase.
4. type
• Is the type of the attribute as another
classifier, typically a class, interface, or built-in
type like int.
17
5. multiplicity
• Specifies how many instances of the attribute's
type are referenced by this attribute.
• Can be absent (meaning multiplicity of 1), a single
integer, or a range of values
• specified between square brackets separated by
".."
• * means zero or more.
18
Attribute Multiplicity
19
Multiplicity ( Attributes and Classes)
Multiplicity applies to attributes, as well. You can specify the
multiplicity of an attribute by writing a suitable expression in brackets
just after the attribute name. For example, in the figure, there are
two or more consolePort instances in the instance of
NetworkController.
20
6. default
• Is the default value of the attribute
21
Attributes
[visibility] name [multiplicity] [: type]
[= initial-value] [{property-string}]
22
23
24
7. Navigation
25
8. Role Names
26
Relationships
27
1. Association
28
2. Generalization
29
3. Dependency
30
4. Aggregation /
Whole Part Relationship
31
32
5. Composition
33
34
Relationships in the hierarchy of
strength
35
36
37
38
39
Derived Attribute
40
41
Post Conditions on Operations
42
43
44
Class diagrams commonly contain the
following things:
· Classes
· Interfaces
· Collaborations
· Dependency, generalization, and association
relationships
45
Purposes of Class Diagram:
• 1. To model the vocabulary of a system
• Modeling the vocabulary of a system involves making a decision about
which abstractions are a
• part of the system under consideration and which fall outside its
boundaries. You use class
• diagrams to specify these abstractions and their responsibilities.
• Collaborations are discussed in Chapter 27.
• 2. To model simple collaborations
• A collaboration is a society of classes, interfaces, and other elements
that work together to
• provide some cooperative behavior that's bigger than the sum of all
the elements. For example,
• when you're modeling the semantics of a transaction in a distributed
system, you can't just stare
46
• of classes that work together. You use class diagrams to visualize
and specify this set of classes
• and their relationships.
• Persistence is discussed in Chapter 23; modeling physical databases
is discussed in Chapter
• 29.
• 3. To model a logical database schema
• Think of a schema as the blueprint for the conceptual design of a
database. In many domains,
• you'll want to store persistent information in a relational database
or in an object-oriented
• database. You can model schemas for these databases using class
diagrams
47
Association Classes
• An association class is a class that is part of an
association relationship between two other
classes.
• You can attach an association class to an
association relationship to provide additional
information about the relationship. An
association class is identical to other classes
and can contain operations, attributes,
48
49
• FootballPlayer may not have a direct reference
to FootballLeague but may have a reference
to FootballTeam instead.
FootballTeam would then have a reference to
FootballLeague
50
Interface
• An interface is a classifier that has declarations
of properties and methods but no
implementations.
• Contr act.
51
52
Provided and Required interfaces
53
Realization Relationship
• A class is said to realize an interface if it
provides an implementation for the
operations and properties.
54
55
Realization vs Dependency
wrt
Interfaces
56
57
58
Association Qualifier
59
• In a banking application, a class called Bank
represents a banking institution and has an
association with a class called Person, which
represents an individual.
• The account number qualifies the association, and
it enables the indexing of many associations
between the Person and Bank classes.
60
Constraints
61
OBJECT Diagram
62
• An object diagram is a diagram that shows a set
of objects and their relationships at a point in
time.
• Graphically, an object diagram is a collection of
vertices and arcs
63
• You use object diagrams to show snapshots of
the relationships in your system
64
• The terms "instance" and "object" are largely
synonymous and so, for the most part, may be
used interchangeably.
• An instance is a concrete manifestation of an
abstraction to which a set of operations may be
applied and which may have a state that stores
the effects of the operation
65
66
Orphan Attribute
67
68
69
The UML defines two standard stereotypes that apply to
the dependency relationships among objects and among
classes:
1. instanceOf:
Specifies that the client object is an instance of the
supplier classifier
2. instantiate:
Specifies that the client class creates instances of the
supplier class
70
71
• Object diagrams commonly contain
• · Objects
• · Links
• Like all other diagrams, object diagrams may
contain notes and constraints
72
You use object diagrams to model the static
design view or static process view of a
system just
as you do with class diagrams, but from the
perspective of real or prototypical instances.
This
view primarily supports the functional
requirements of a system• that is, the
services the system
should provide to its end users. Object
diagrams let you model static data
structures.
73
If class A has a one-to-many association to
class B, then
for one instance of A there might be five
instances of B; for another instance of A there
might be
only one instance of B. Furthermore, at a given
moment in time, that instance of A, along with
the related instances of B, will each have
certain values for their attributes and state
machines.
If you freeze a running system or just imagine a
moment of time in a modeled system, you'll
find a
set of objects, each in a specific state, and
each in a particular relationship to other
objects. You
can use object diagrams to visualize, specify,
construct, and document the structure of
these
objects. Object diagrams are especially useful
for modeling complex data structures
74
• Therefore, when you use
• object diagrams, you can only meaningfully
expose interesting sets of concrete or
prototypical
• objects. This is what it means to model an
object structure• an object diagram shows
one set of
• objects in relation to one another at one
moment in time.
75
Task:
• Class Diagram
• Object Diagram
76
Aggregation implies a relationship where
the child can exist independently of the
parent
• Composition implies a relationship where the
child cannot exist independent of the parent
77
COMPONENT DIAGRAM
• Interfaces and Components
78
• A component is a replaceable, executable
piece of
a
larger
system
whose
implementation details are hidden.
• .
79
The functionality provided by a component is
specified by a set of provided interfaces that the
component realizes
In addition to providing interfaces, a component
may require interfaces in order to function. These
are called required interfaces
80
UML VERSION 2.0
81
Component
Diagram
82
Component Views
UML uses two views of components, a black-box
view and a white-box view.
83
The black-box view shows a component from
an outside perspective;
the white-box view shows how a component
realizes the functionality specified by its
provided interfaces.
84
Black-Box View
•
•
•
•
The black-box view of a component shows the
interfaces the component provides,
the interfaces it requires,
and any other detail necessary to explain the
guaranteed behavior of the component.
• It does not specify anything about the internal
implementation of the component. This
distinction is central to the concept of
replaceable components.
85
Black Box View
• 1. Assembly connectors
2. Interface Dependencies
3. Component Compartments
86
1. Assembly connectors
• When modeling a black-box view of a
component, you represent the provided and
required interfaces using assembly connectors.
• Assembly connectors are illustrated using
ball and socket icons
87
88
• To wire components together, simply connect
the matching provided and required
interfaces.
• Component dependencies using assembly
connectors provide more details about the
actual
• relationships between components than
simple dependency relations
89
90
2. Interface Dependencies
91
92
3. Component Compartments
Use the stereotype::
«provided interfaces»
«required interfaces»
95
96
97
Black Box View
• 1. Assembly connectors
2. Interface Dependencies
3. Component Compartments
98
White Box view
• In order to provide details about the
implementation of a component, UML defines a
white box view.
• The white-box view shows exactly how a
component realizes the interfaces it provides.
• This is typically done using classes and is
illustrated with a class diagram; however a
component may delegate some or all of its
behavior to other components.
99
Level 1
100
Detailed Realization
Level 2
101
Level 3
102
Ports
• Ports provide a way to model how a
component's provided/required interfaces
relate to its internal elements.
103
Levels of Abstraction in Component
Diagram
White Box View
• Level 1: High level
• Level 2: lower than 1
• Level 3: lowest
104
105
Task
106
ENDS ……..
107
108
• Level 1: High level - Component Dependencies
• Level 2:Ball and socket Notation
• Level 3: Realization and Dependency relations
109
DEPLOYMENT DIAGRAM
• Deployment diagrams model the mapping of
software pieces of a system to the hardware
that is going to execute it.
110
ELEMENTS OF DEPLOYMENT
DIAGRAM
•
•
•
•
Artifact
Nodes
Devices
Communication Paths
111
1. Artifact
• Artifacts represent physical pieces of information
related to the software development process.
•
•
•
•
•
For example, you can use an artifact to represent
a DLL needed by your system,
A user's manual, or
an executable produced
Typically artifacts are used to represent the
compiled version of a component
112
113
114
2. Node
• A node is a physical entity that can execute
artifacts.
• Nodes can vary in size from a simple embedded
device to a server.
• Nodes are a critical piece of any deployment
diagram because they show where a particular
piece of code executes and how the various
pieces of the system (at the execution level)
communicate.
115
• You show a node as a 3D box with the name of
the node written inside
116
117
2. Device
• A device is a specialization of a node that
represents a physical machine capable of
performing calculations.
• You show a device as a node with the
stereotype «device>>
118
119
• One of the more powerful features of devices
is that they can be nested.
• For example,
• You can model a server with internal devices
representing RAID controllers, video cards,
etc.
• A real-world use of nested devices can be pixel
and vertex shading code running on a video
card (represented as a device) while the rest
of the application runs on the machine's CPU
120
121
3. Execution Environment
• An execution environment is a specialized node
that represents a software configuration hosting
specific types of artifacts.
• An execution environment is expected to provide
specific services to hosted artifacts by means of
mutually agreed upon interfaces.
122
123
124
125
4. COMMUNICATION PATHS
• Because many nodes may be associated with
the deployment of a system, communication
between nodes can be modeled using
communication paths
• Communication paths represent
communication between nodes.
generic
126
127
128
129
Deployment diagram
130
DEPLOYMENT DIAGRAM ends..
131
PACKAGE DIAGRAM
132
Package diagrams
• Packages provide a way to group related UML
elements and scope their names.
• For example,
• you can put all elements having to do with 3D
rendering into a package named 3DGraphics.
• Package diagrams provide a great way to visualize
dependencies between parts of your system and
are often used to look for problems or determine
compilation order.
133
• Package may contain any other UML
elements, including another package .
134
135
136
• You place a circle with a plus sign in it at the
end nearest the package to indicate
containment
137
138
Visibility
139
140
Importing and Accessing Package
141
Using a Qualifier
• When accessing elements in one package from a
different package, you must qualify the name of
the element you are accessing.
• For example, if Car is a class in the transportation
package and you are trying to access it from a
package named RoutePlanning, you need to
qualify Car as
transportation::Car
Package
Class
142
Importing Package
Imported Package
143
To simplify accessing elements in a different package,
UML allows a package to import another package.
Elements of the imported package are available
without qualification in the importing package.
So, if the RoutePlanning package imported the
transportation package, you can refer to Car without any
qualifications from within the RoutePlanning package
144
145
By default, imported elements are given public
visibility in the importing package.
UML allows you to specify that imported elements
should be given private visibility, meaning they can't
be used by anyone outside the package
To specify that imported elements should have
private visibility, you use the «access» keyword
rather than the «import» keyword
146
147
Figure shows the RoutePlanning package importing
the Transportation package and accessing the
Algorithms package.
If a package imports the RoutePlanning package, both
packages can use public elements from Transportation,
but they can't use anything in Algorithms.
148
1.
• Package Diagram drawn by a
Project Manager
149
150
151
2. Use Case Package
• Use case packages organize the functional
behavior of a system.
• You manage the use case packages to manage
the project.
152
153
3. Directed Dependency Graph
• Directed dependency graphs of the packages in a
system reveal nonfunctional issues related to
buildability, testability, and robustness;
• they provide a guide for several roles in software
development.
154
155
When all the dependencies flow in one direction,
without any loops or cycles, the graph is acyclic .
Acyclic graphs show a project in good health.
156
• Cycles - > pain for stakeholders.
157
158
159
160
161
162
IMPORT
• When a package imports another package, elements in
the importing package can use elements in the
imported package without having to use their fully
scoped names. This feature is similar to a Java import,
in which a class can import a package and use its
contents without having to provide their package
names.
• In an import relationship, the imported package is
referred to as the target package . To show the import
relation, draw a dependency arrow from the importing
package to the target package with the
stereotype import
163
When importing a package, only public elements
164
165
166
167
168
169
170
171
172
UNIT 2 ends
173