1. UNIT 2
STATIC MODELING

2. Class Diagrams
Object Diagrams
Component Diagrams
Deployment Diagrams
Package Diagrams

3. A classifier is a mechanism that describes structural and behavioral features.
Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.

4. Classifiers

5. CLASS DIAGRAM Books: UML in a Nutshell by Dan Pilone UML User Guide
UML 2 & the Unified Process by Jim Arlow

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

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

8. UML suggests that the class name:
Start with a capital letter
Be centered in the top compartment
Be written in a boldface font

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

10. Attributes
Inlined Attributes

11. Inlined Attributes
You can list a class's attributes right in rectangle notation; these are typically called inlined attributes

12. 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. Use the following symbols: +, -, #, ~ for public, private, protected, or package, respectively

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

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

15. Visibility

16. 2. Derived Attribute
/ Indicates the attribute is derived. A derived attribute is simply one that can be computed from other attributes of the class.

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

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

19. Attribute Multiplicity

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

21. 6. default
Is the default value of the attribute

22. Attributes
[visibility] name [multiplicity] [: type] [= initial-value] [{property-string}]

25. 7. Navigation

26. 8. Role Names

27. Relationships

28. 1. Association

29. 2. Generalization

30. 3. Dependency

31. 4. Aggregation / Whole Part Relationship

33. 5. Composition

35. Relationships in the hierarchy of strength

40. Derived Attribute

42. Post Conditions on Operations

45. Class diagrams commonly contain the following things:
· Classes
· Interfaces
· Collaborations
· Dependency, generalization, and association relationships

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

47. of classes that work together
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

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

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

51. Interface
An interface is a classifier that has declarations of properties and methods but no implementations.
Contr act.

53. Provided and Required interfaces

54. Realization Relationship
A class is said to realize an interface if it provides an implementation for the operations and properties.

56. Realization vs Dependency wrt Interfaces

59. Association Qualifier

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

61. Constraints

62. OBJECT Diagram

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

64. You use object diagrams to show snapshots of the relationships in your system

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

67. Orphan Attribute

70. The UML defines two standard stereotypes that apply to the dependency relationships among objects and among classes:
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

72. Object diagrams commonly contain
· Objects
· Links
Like all other diagrams, object diagrams may contain notes and constraints

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

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

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

76. Task:
Class Diagram
Object Diagram

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

78. COMPONENT DIAGRAM
Interfaces and Components

79. A component is a replaceable, executable piece of a larger system whose implementation details are hidden. .

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

81. UML VERSION 2.0

82. Component Diagram

83. Component Views
UML uses two views of components, a black-box view and a white-box view.

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

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

86. 2. Interface Dependencies 3. Component Compartments
Black Box View
1. Assembly connectors
2. Interface Dependencies
3. Component Compartments

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

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

91. 2. Interface Dependencies

93. 3. Component Compartments
Use the stereotype:: «provided interfaces» «required interfaces»

96. 2. Interface Dependencies 3. Component Compartments
Black Box View
1. Assembly connectors
2. Interface Dependencies
3. Component Compartments

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

98. Level 1

99. Detailed Realization
Level 2

100. Level 3

101. Ports
Ports provide a way to model how a component's provided/required interfaces relate to its internal elements. 

102. Levels of Abstraction in Component Diagram White Box View
Level 1: High level
Level 2: lower than 1
Level 3: lowest

104. Task

105. ENDS ……..

107. Level 1: High level - Component Dependencies
Level 2:Ball and socket Notation
Level 3: Realization and Dependency relations

108. DEPLOYMENT DIAGRAM
Deployment diagrams model the mapping of software pieces of a system to the hardware that is going to execute it.

109. ELEMENTS OF DEPLOYMENT DIAGRAM
Artifact
Nodes
Devices
Communication Paths

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

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

114. You show a node as a 3D box with the name of the node written inside

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

124. 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 generic communication between nodes.

128. Deployment diagram

129. DEPLOYMENT DIAGRAM ends..

130. PACKAGE DIAGRAM

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

132. Package may contain any other UML elements, including another package .

135. You place a circle with a plus sign in it at the end nearest the package to indicate containment

137. Visibility

139. Importing and Accessing Package

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

141. Importing Package
Imported Package

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

147. 1.
Package Diagram drawn by a
Project Manager

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

155. Cycles - > pain for stakeholders.

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

162. When importing a package, only public elements of the target package are available in the importing namespace. For example, in Figure 13-16, elements in users can see Credentials and IdentityVerifier but not MD5Crypt.

171. UNIT 2 ends