1. CHAPTER

2. Agenda
UML
UML Elements
Relationships
Diagrams
Class Diagram

3. Foreword
We prepare UML diagrams to understand a system in better and simple way.
A single diagram is not enough to cover all aspects of the system.
So UML defines various kinds of diagrams to cover most of the aspects of a system.
You can also create your own set of diagrams to meet your requirements.
Diagrams are generally made in an incremental and iterative way.

4. 1.2 Behavioral Things
A behavioral thing consists of the dynamic parts of UML models.
Following are the behavioral things:
Interactions: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.
State Machines: useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

5. 1.3 Grouping Things and 1.4 Annotational Things
Grouping things can be defined as a mechanism to group elements of a UML model together.
Package is the only one grouping thing available for gathering structural and behavioral things.
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements.
Note is the only one Annotational thing available. A note is used to render comments, constraints etc of an UML element.

6. Notations

7. 2. Relationships It shows how elements are associated with each other.
This association describes the functionality of an application.
There are four kinds of relationships available:
Dependency: relationship between two things in which change in one element also affects the other one.
Association: is basically a set of links that connects elements of an UML model
Generalization: It basically describes inheritance relationship in the world of objects
Realization: This relationship exists in case of interfaces

8. Notations of Relationships

9. 3. UML Diagrams
UML diagrams are the ultimate output of the entire discussion (systems design).
All the elements, relationships are used to make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process.

10. UML Diagrams (cont) Structural Modeling Behavioral Modeling
Class and Object diagram
Package Diagrams
Deployment Diagram
Component Diagram
Behavioral Modeling
Use case diagram
Activity Diagrams
Sequence diagram

11. Class Diagrams
Is static diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects.
Class diagrams basically represent the object oriented view of a system which is static in nature.
Active class is used in a class diagram to represent the concurrency of the system.

12. Class Diagrams Visibility
To specify the visibility of a class member (i.e., any attribute or method), these notations must be placed before the member's name
+ Public
- Private
# Protected
/ Derived (can be combined with one of the others)
~ Package

13. Example: Person's class diagram

14. Relationships in class diagrams
Composition
Inheritance
Aggregation
Association
Realization
Multiplicity

15. Association
Association represents the static relationship shared among the objects of two classes.
A binary association (with two ends) is normally represented as a line.
An association can link any number of classes. An association with three links is called a ternary association.
An association can be named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties.

16. Composition
Composition usually has a strong life cycle dependency between instances of the container class and instances of the contained class(es): if the container is destroyed, normally every instance that it contains is destroyed as well.
Each instance of type Circle seems to contain an instance of type Point. This is a relationship known as composition.
Forms a HAS-A relationship
Indicated by a filled-up diamond-faced arrow

17. Inheritance Also called generalization
It indicates that one of the two related classes (the subclass) is considered to be a specialized form of the other (the super type) and the superclass is considered a 'Generalization' of the subclass.
In practice, this means that any instance of the subtype is also an instance of the superclass
Forms an IS-A relationship

18. Aggregation
Aggregation can occur when a class is a collection or container of other classes, but the contained classes do not have a strong life cycle dependency on the container.
The contents of the container are not automatically destroyed when the container is.
Aggregation is a variant of the "has a" association relationship; aggregation is more specific than association.
It is an association that represents a part- whole or part-of relationship

19. Realization
Is a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behavior that the other model element (the supplier) specifies.
A hollow triangle shape on the interface end of the dashed line (or tree of lines) that connects it to one or more implementers.
A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element

20. Multiplicity
This association relationship indicates that (at least) one of the two related classes make reference to the other.
This relationship is usually described as "A has a B" (a mother cat has kittens, kittens have a mother cat).
Each end of the association has an upper multiplicity boundary and a lower multiplicity boundary.

21. Multiplicity (continued)
The Multiplicity Cardinality table is below
0..* Zero or more instances
1..* At least one instance
5..5 Exactly 5 instances
m..n At least m but no more than n instances

22. Case Study : Hospital Management System

23. Class diagram Example 2

24. Object Diagram
Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams
Object diagrams represent an instance of a class diagram.
Object diagrams also represent the static view of a system but this static view is a snapshot of the system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an instance

25. How to draw Object Diagrams
First, analyze the system and decide which instances are having important data and association.
Second, consider only those instances which will cover the functionality.
Third, make some optimization as the numbers of instances are unlimited.

26. How to draw object diagrams (contd)
The object diagram should have a meaningful name to indicate its purpose.
The most important elements are to be identified.
The association among objects should be clarified.
Values of different elements need to be captured to include in the object diagram.
Add proper notes at points where more clarity is required.

27. Example: Order Management System

28. Where to use Object Diagram
Object diagrams can be imagined as the snapshot of a running system at a particular moment.
Now if you take a snap of the running train then you will find a static picture of it having the following:
A particular state which is running
A particular number of passengers. which will change if the snap is taken in a different time.

29. 2. Component Diagram
Component diagrams are used to model physical aspects of a system.
Physical aspects are the elements like executables, libraries, files, documents etc which resides in a node
So component diagrams are used to visualize the organization and relationships among components in a system.
These diagrams are also used to make executable systems.

30. Purpose of Component Diagrams
It does not describe the functionality of the system but it describes the components used to make those functionalities.
So from that point component diagrams are used to visualize the physical components in a system. These components are libraries, packages, files etc.
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components

31. How to Draw Component Diagrams
So before drawing a component diagram the following artifacts are to be identified clearly:
Files used in the system.
Libraries and other artifacts relevant to the application.
Relationships among the artifacts.
Now after identifying the artifacts the following points needs to be followed:
Use a meaningful name to identify the component for which the diagram is to be drawn.
Prepare a mental layout before producing using tools.
Use notes for clarifying important points.

32. Example: Order Management System

33. Where to use component Diagrams
Model the components of a system.
Model database schema.
Model executables of an application.
Model system's source code.

34. 3. Deployment Diagrams
Deployment diagrams are used to visualize the topology of the physical components of a system where the software components are deployed.
So deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships.

35. Purpose of Deployment Diagrams
Deployment diagrams are used for describing the hardware components where software components are deployed.
Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware.
The purpose of deployment diagrams can be described as:
Visualize hardware topology of a system.
Describe the hardware components used to deploy software components.
Describe runtime processing nodes.

36. How to draw Deployment Diagram?
An efficient deployment diagram is very important because it controls the Performance, Scalability, Maintainability, Portability.
So before drawing a deployment diagram the following artifacts should be identified:
Nodes
Relationships among nodes

37. Example

38. Where to use deployment Diagrams
To model the hardware topology of a system.
To model embedded system.
To model hardware details for a client/server system.
To model hardware details of a distributed application.
Forward and reverse engineering.

39. Behavioral Diagrams

40. Use case Diagrams
To model a system the most important aspect is to capture the dynamic behavior - the behavior of the system when it is running /operating.
Models internal or external factors for making the interaction with the software system
These internal and external agents are known as actors.
So use case diagrams are consists of actors, use cases and their relationships.
A single use case diagram captures a particular functionality of a system.

41. Purpose Used to gather requirements of a system.
Used to get an outside view of a system.
Identify external and internal factors influencing the system.
Show the interacting among the requirements are actors

42. How to draw Use Case Diagram
choose a name in such a way so that it can identify the functionalities performed.
Give a suitable name for actors.
Show relationships and dependencies clearly in the diagram.
Do not try to include all types of relationships. Because the main purpose of the diagram is to identify requirements.
Use note when ever required to clarify some important points.

43. Example: Order System

44. Example2: Hospital Management System

45. Where ??
Use case diagrams specify the events of a system and their flows.
But use case diagram never describes how they are implemented.
Use case diagram can be imagined as a black box where only the input, output and the function of the black box is known.
Requirement analysis and high level design.
Model the context of a system.
Reverse engineering.
Forward engineering.

46. Interaction Diagrams
From the name Interaction it is clear that the diagram is used to describe some type of interactions among the different elements in the model.
So this interaction is a part of dynamic behaviour of the system.
This interactive behaviour is represented in UML by two diagrams known:
Sequence diagram
Collaboration diagram.

47. Purpose To capture dynamic behaviour of a system.
To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.

48. How to draw interaction diagrams
Objects taking part in the interaction.
Message flows among the objects.
The sequence in which the messages are flowing.
Object organization.

49. Sequence Diagram Example

50. Collaboration Diagrams
The second interaction diagram is collaboration diagram.
It shows the object organization
In collaboration diagram the method call sequence is indicated by some numbering technique
We have taken the same order management system to describe the collaboration diagram.

51. Example

52. Where to use collaboration diagrams
Sequence diagrams are used to capture the order of messages flowing from one object to another.
And the collaboration diagrams are used to describe the structural organizations of the objects taking part in the interaction.
Usages of collaboration diagrams:
To model flow of control by time sequence.
To model flow of control by structural organizations.
For forward engineering.
For reverse engineering.

53. 4. State Charts
It describes different states of a component in a system.
The states are specific to a component/object of a system.
A Statechart diagram describes a state machine.
A state machine can be defined as a machine which defines different states of an object and these states are controlled by external or internal events.

54. Purpose
Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system.
They define different states of an object during its lifetime.
And these states are changed by events.
So Statechart diagrams are useful to model reactive systems.
Reactive systems can be defined as a system that responds to external or internal events.
Statechart diagram describes the flow of control from one state to another state.
States are defined as a condition in which an object exists and it changes when some event is triggered.

55. How to draw a stateChart
Statechart diagram is used to describe the states of different objects in its life cycle.
So the emphasis is given on the state changes upon some internal or external events.
How?:
Identify important objects to be analyzed.
Identify the states.
Identify the events.

56. Example

57. 5. Activity Diagram
Activity diagram is basically a flow chart to represent the flow form one activity to another activity.
The activity can be described as an operation of the system.
So the control flow is drawn from one operation to another.
This flow can be sequential, branched or concurrent.
Activity diagrams deals with all type of flow control by using different elements like fork, join etc

58. Purpose So the purposes can be described as:
Draw the activity flow of a system.
Describe the sequence from one activity to another.
Describe the parallel, branched and concurrent flow of the system.

59. How to draw activity diagrams
The main element of an activity diagram is the activity itself. An activity is a function performed by the system.
After identifying the activities we need to understand how they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:
Activities
Association
Conditions
Constraints

60. Example

61. Assignment 2 :
Draw the following UML diagrams for the Hospital Management System (10 marks)
1. Class Diagram
2. Component Diagram
3. Deployment Diagram
4. Use case diagram
5. Sequence Diagram