1. OBJECT MODELLING USING UML
UML is a modelling language used for creating models.
Not a system design or development methodology.
Used to document result of object-oriented analysis and design.
Independent of any specific design methodology

2. OBJECT MODELLING USING UML
Provides set of notations(e.g. rectangles, lines etc.) to create a visual model of the system.
UML has its own syntax and semantics.

3. UNIFIED MODELLING LANGUAGE (UML)
Origin
In late 1980s and early 1990s different software development houses were using different notations to document object oriented designs.
Developed in early 1990s to standardize the large number of object-oriented modelling notations

4. UML
UML was developed to standardize the large number of object-oriented modeling notations that existed and were used extensively in the early 1990s.
Based Principally on
OMT [Rumbaugh 1991]
Booch’s methodology[Booch 1991]
OOSE [Jacobson 1992]
Odell’s methodology[Odell 1992]
Shlaer and Mellor [Shlaer 1992]

5. UML OMT UML Booch Methodology OOSE
Different object modelling techniques in UML

6. UML As a Standard Adopted by Object Management Group (OMG) in 1997
OMG an association of industries
Promote extensive set of notations and techniques
Used outside software development, example car manufacturing

7. WHY UML IS REQUIRED? Required to capture only important aspects
UML a graphical modelling tool, easy to understand and construct
Helps in managing complexity

8. UML DIAGRAMS
Construct Nine diagrams to capture five different views of a system
Provide different perspectives of the software system
Diagrams can be refined to get the actual implementation of the system

9. UML DIAGRAMS Five Views of a system User’s view Structural view
Behavioral view
Implementation view
Environmental view

10. UML DIAGRAMS Diagrams and views in UML Behavioural View
User’s View
Use Case
Diagram
Structural View
Class Diagram
Object Diagram
Implementation View
Component Diagram
Environmental View
Deployment Diagram
Behavioural View
Sequence Diagram
Collaboration Diagram
- State-chart Diagram
- Activity Diagram
Diagrams and views in UML

11. USER’S VIEW
Defines the functionalities (facilities) made available by the system to its users.
Black-box view of the system
- where the internal structure, the dynamic behaviour of different system components, the implementation etc. are not visible.
Considered as the central view and all other views are expected to conform to this view.

12. STRUCTURAL VIEW
Defines the kinds of objects important to the understanding of the working of a system and to its implementation.
Captures the relationships among the objects.
Called the static model, since the structure of a system does not change with time.

13. BEHAVIORAL VIEW
Captures how objects interact with each other to realize the system behavior.
Captures the time-dependent (dynamic) behavior of the system.

14. IMPLEMENTATION VIEW
Captures the important components of the system and their dependencies.

15. ENVIRONMENTAL VIEW
Models how the different components are implemented on different pieces of hardware.

16. NO ARE ALL VIEWS REQUIRED?
Use case model, class diagram and one of the interaction diagram for a simple system
State chart diagram in case of many state changes
Deployment diagram in case of large number of hardware components

17. USE CASE MODEL Consists of set of “use cases”
An important analysis and design artifact
Other models must confirm to this model
Not really an object-oriented model
Represents a functional or process model

18. USE CASES Different ways in which system can be used by the users
Corresponds to the high-level requirements
Represents transaction between the user and the system
Define behavior without revealing internal structure of system
Set of related scenarios tied together by a common goal

19. USE CASES Use cases are independent of each other
Implicit dependencies may exist

20. EXAMPLE OF USE CASES For library information system issue-book
Query-book
Return-book
Create-member
Add-book, etc.

21. REPRESENTATION OF USE CASES
Represented by use case diagram
Use case is represented by ellipse
System boundary is represented by rectangle
Users are represented by stick person icon (actor)
Communication relationship between actor and use case by line
External system by stereotype

22. EXAMPLE OF USE CASES TIC-TAC-TOE
Use case model
Tic-tac-toe game
Play Move
Player

23. WHY DEVELOP USE CASE DIAGRAM?
Serves as requirements specification
Users identification helps in implementing security mechanism through login system
Another use in preparing the documents (e.g. user’s manual)

24. FACTORING USE CASES
Complex use cases need to be factored into simpler use cases
Represent common behavior across different use cases
Three ways of factoring
Generalization
Includes
Extends

25. GENERALIZATION
Generalization works the same way with use cases as it does with classes.
The child use case inherits the behavior and meaning of the parent use case.
The base and the derived use cases are separate use cases and should have separate text descriptions.

26. FACTORING USING GENERALIZATION
Pay membership fee
Pay through library pay card
Pay through credit card
Use case generalization

27. INCLUDES
Involves one use case including the behavior of another use case in its sequence of events and actions.
The includes relationship occurs when a chunk of behavior that is similar across a number of use cases.
As shown in fig., the includes relationship is represented using a predefined stereotype <<include>>.

28. FACTORING USING INCLUDES
Base use case
Use case inclusion
Common
use case
<<include>>
Issue Book
Update
selected
book
Get user
selection
Check for
reservation
Renew Book
<<include>>
Paralleling model

29. EXTENDS It allows you to show optional system behavior.
This relationship among use cases is also predefined as a stereotype <<extends>> as shown in fig..
Similar to generalization but the extending use case can add additional behavior only at an extension point only when certain conditions are satisfied.
The extends relationship is normally used to capture alternate paths or scenarios.

30. FACTORING USING EXTENDS
Base
use case
Use case extension
Common
<<extends>>

31. ORGANIZATION OF USE CASES
When the use cases are factored, they are organized hierarchically.
The high-level use cases are refined into a set of smaller and more refined use cases as shown in fig.
Top-level use cases are super-ordinate to the refined use cases.

32. ORGANIZATION OF USE CASES
The refined use cases are sub-ordinate to the top-level use cases.
Only the complex use cases should be decomposed and organized in a hierarchy.
This level is also referred to as the context diagram.

33. HIERARCHICAL ORGANIZATION OF USE CASES
External users
use case 3.1
use case 3. 2
use case 3.3
Subsystems
use case 1
use case 2
use case 3
Method
Hierarchical organization of use cases

34. CLASS DIAGRAM Describes static structure of a system.
Shows how a system is structured rather than how it behaves.
Main constituents are classes and their relationships:
Generalization
Aggregation
Association
Various kinds of dependencies

35. CLASS Entities with common features, i.e. attributes and operations
Classes are represented as solid outline rectangle with compartments
Classes have a mandatory name compartment where the name is written centered in boldface.

36. CLASS
The class name is usually written using mixed case convention and begins with an uppercase.
The class names are usually chosen to be singular nouns.
Attribute and operation compartment are optional for reuse purpose

37. ATTRIBUTES An attribute is a property of a class.
Represents kind of data that an object might contain.
Type of the attribute is written by appending a colon and the type name after the attribute name.
First letter of a attribute is a small letter.
Example :
bookName : String

38. OPERATION
Implementation of a service that can be requested from any object.
An object’s data or state can be changed by invoking an operation of the object.
A class may have any number of operations or no operation at all.
First letter of an operation name is a small letter.
Abstract operations are written in italics.

39. OPERATION The parameters of an operation may be
- ‘in’, ‘out’ or ‘inout’.
Example:
issueBook(in bookName):Boolean

40. EXAMPLE OF CLASS DIAGRAM
LibraryMember
Member Name
Membership Number
Address
Phone Number
Address
Membership Admission Date
Membership Expiry Date
Books Issued
issueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );
LibraryMember
LibraryMember
Member Name
Membership Number
Address
Phone Number
Address
Membership Admission Date
Membership Expiry Date
Books Issued
Different representations of the LibraryMember class

41. ASSOCIATION RELATIONSHIP
Enable objects to communicate with each other
Describes a connection between classes.
The association relation between two objects is called object connection or link.
Usually binary relation but more classes can be involved

42. ASSOCIATION RELATIONSHIP
Class can have relationship with itself (recursive association)
Association between two classes is represented by drawing a straight line
The name of the association is written along side the association line.
Arrowhead used along with name indicates reading direction of association
Multiplicity indicates how many instances of one class are associated with each other.

43. ASSOCIATION RELATIONSHIP
Association between two classes
Library Member
Book 1 *
borrowed by

44. AGGREGATION RELATIONSHIP
Involved classes are not only associated to each other but also represent a whole-part relationship
Example: a book register is an aggregation of book object.
Represented by diamond symbol at the composite end

45. AGGREGATION RELATIONSHIP
Cannot be reflexive(i.e. recursive)
- an object cannot contain objects of the same class as itself.
Not symmetric
- Two classes A and B cannot contain instances of each other.
It can be transitive
- Consist of an arbitrary number of levels.

46. AGGREGATION RELATIONSHIP
Representation of aggregation
Document
Line 1 *
Paragraph

47. COMPOSITIONRELATIONSHIP
Composition is a stricter form of aggregation.
Parts are existence-dependent on the whole.
When the whole is created, the parts are created and when the whole is destroyed, the parts are destroyed.
Represented as a filled diamond drawn at the composite-end.

48. COMPOSITION RELATIONSHIP
Order 1 *
Item
Representation of composition

49. INHERITANCE RELATIONSHIP
Inheritance describes ‘is a’ / ‘is a kind of’ relationship between classes .
Inheritance is defined statically.
It can not be changed at run-time.

50. INHERITANCE RELATIONSHIP

51. OBJECT DIAGRAM Shows the snapshot of the objects in a system.
Shows instances of classes rather than classes themselves, often called instance diagram.
Undergo continuous change as execution proceeds.
Useful to explain the working of a system.

52. OBJECT DIAGRAM Different representations of the LibraryMember object
Mritunjay
B10028
C-108, Laksmikant Hall
1119
NIL
IssueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );
LibraryMember
Mritunjay
B10028
C-108, Laksmikant Hall
1119
NIL
LibraryMember
Different representations of the LibraryMember object

53. INTERACTION DIAGRAM
Models that describes how groups of objects interact among themselves.
Each interaction diagram realizes behaviour of a single use case

54. INTERACTION DIAGRAM Two kinds: Sequence & Collaboration
Two diagrams are equivalent in the sense that any one diagram can be derived automatically from the other but portrays different perspective
These diagram play a very important role in the design process

55. SEQUENCE DIAGRAM
Shows interaction among objects as two- dimensional chart
The chart is read from top to bottom.
Objects are shown as boxes at top of chart.
Inside the box the name of the object is written with a colon separating it from the name of the class.

56. SEQUENCE DIAGRAM
Both the name of the object and the class are underlined
The objects appearing at the top signify object already existed when the use case execution was initiated.
If object created during execution then shown at appropriate place.

57. SEQUENCE DIAGRAM
Objects existence are shown as dashed lines (object’s lifeline)
Objects activeness, shown as rectangle on lifeline called activation symbol.
Messages are shown on arrows

58. SEQUENCE DIAGRAM Message labelled with message name
Message can be labelled with control information
Two types of control information: condition ([]) & an iteration (*)

59. EXAMPLE OF SEQUENCE DIAGRAM
The sequence diagram for the book renewal use case for the Library Automation Software is shown in fig.

60. EXAMPLE OF SEQUENCE DIAGRAM
:Library
Boundary
Book
Renewal
Controller
Register
:Book
Member
renewBook
displayBorrowing
selectBooks
[reserved]
apology
confirm
find MemberBorrowing
bookSelected
* find
update
updateMemberBorrowing
Sequence Diagram for the renew book use case

61. COLLABORATION DIAGRAM
Shows both structural and behavioural aspects
The structural aspect consists of objects and the links existing between them.
Objects are collaborator, shown as boxes
The behavioral aspect is described by the set of messages exchanged among the different collaborators

62. COLLABORATION DIAGRAM
Link between objects shown as a solid line.
Message is shown as a labelled arrow placed near the link
Messages are prefixed with sequence numbers to show relative sequencing

63. EXAMPLE OF COLLABORATION DIAGRAM
:Library
Boundary
Book
Renewal
Controller
Register
:Book
Member
1: renewBook
3: display
Borrowing
4: selectBooks
[reserved]
8: apology
12: confirm
2: findMemberBorrowing
5: book
Selected
6: * find
9: update
7: apology
10: confirm
updateMemberBorrowing
Collaboration Diagram for the renew book use case

64. ACTIVITY DIAGRAM
New concept, possibly based on event diagram of Odell [1992]
Represent processing activity, may not correspond to methods of classes
Activity is a state with an internal action and one/many outgoing transition

65. ACTIVITY DIAGRAM Normally employed in business process modelling
Carried out during requirement analysis and specification
Can be used to develop interaction diagrams

66. ACTIVITY DIAGRAM
Can represent parallel activity and synchronization aspects
Important feature of activity diagram
- Swim lanes
- enable to group activities based on who is performing them
Example: academic department vs. hostel

67. EXAMPLE OF ACTIVITY DIAGRAM
The student admission process in IIT is shown as an activity diagram. This shows the part played by different components of the Institute in the admission procedure. After the fees are received at the account section, parallel activities start at the hostel office, hospital, and the Department. After all these activities complete (this synchronization is represented as a horizontal line), the identity card can be issued to a student by the Academic section.

68. EXAMPLE OF ACTIVITY DIAGRAM
check
student
records
Academic Section
receive
fees
allot
room
hostel
create
hospital
record
conduct
medical
examination
register in
course
Accounts Section
Hostel Office
Hospital
Department
issue
identity card
Activity diagram for student admission procedure at IIT

69. STATE CHART DIAGRAM Based on the work of David Harel [1990]
Model how the state of an object changes in its lifetime
Describe how the behavior of the object changes across several use case execution.
Based on finite state machine (FSM) formalism

70. WHY STATE CHART DIAGRAM
State chart avoids problem of state explosion as in FSM
State explosion
- The number of states becomes too many and the model too complex.
Hierarchical model of a system and represents composite state (nested)

71. STATE CHART DIAGRAM Elements of state chart diagram
Initial State: Filled circle
Final State: Filled circle inside larger circle
State: Rectangle with rounded corners
Transitions: Arrow between states, also boolean logic condition (guard).
The syntax for the label of the transition is: event[guard]/action.

72. EXAMPLE OF STATE CHART DIAGRAM
An example of state chart for the order object of the Trade House Automation software is shown in fig.

73. EXAMPLE OF STATE CHART DIAGRAM
Unprocessed
Order
Fulfilled
Pending
Accepted
Rejected
order received
[reject] checked
[accept] checked
[some items not
available] processed
[all items
available]
newsupply
[some items available]
processed / deliver
Example: State chart diagram for an order object

74. COMPONENT DIAGRAM
Piece of a software that can be independently purchased, upgraded and integrated into existing software.
Represent the physical structure of implementation

75. COMPONENT DIAGRAM Used for two purposes: Organizing source code
Specify dependencies among different components.

76. DEPLOYMENT DIAGRAM Shows the environmental view of the system.
Shows how the software system will be physically deployed in the hardware environment.
Diagram models the run time architecture of an application.