1. Simple UML
13 Nov 2018

2. What is UML? UML stands for Unified Modeling Language
UML is a diagramming language designed for Object- Oriented programming
UML can be used to describe:
the organization of a program
how a program executes
how a program is used
how a program is deployed over a network
…and more

3. Design Patterns
Design Patterns describe the higher-level organization of solutions to common problems
Design Patterns are a current hot topic in O-O design
UML is always used for Design Patterns
Design Patterns are used to describe refactorings
We will discuss some Design Patterns later on in this course

4. UML is complex UML is a big, complicated diagramming language
UML comprises at least seven or eight different kinds of diagrams
This talk will cover just a tiny bit of one kind of diagram, the class diagram
A class diagram is often all that is needed to describe a particular Design Pattern

5. Class diagrams
A class diagram shows classes, interfaces, and their relationships
We’ll cover most of classes and interfaces, and a few of the most important relationships

6. Classes
A class is drawn as a rectangle with two or three compartments:
Name of the class
Variables [optional]
Methods

7. Variables I A variable is written as: visibility name : type where:
+ means public visibility
# means protected visibility
- means private visibility
<blank> means default (package) visibility
Example: +length:int

8. Variables II Static variables are underlined
An initial value can be shown with =value
Example: numberOfEmployees:int=10 means numberOfEmployees is:
private
static
integer
and has 10 as its initial value

9. Methods
Methods are written as: visibility name (parameters) : returnType where
visibility uses the same syntax variables (+, -, #, blank)
parameters are given as name:type
if the returnType is void, it is omitted
constructors are preceded by «constructor»
interfaces are preceded by «interface»
an ellipsis (…) indicates omitted methods

10. Example of a class Card cardId:int -copy:boolean=false
«constructor» Card(int id)
+isKind(desiredKind:int)
+isSharable():boolean
+toString():String

11. Types of relationshipsB C D
1..4
Factory
Product
creates
Other kinds of relations
Class B extends class A
Class C contains 1 to 4 objects of class D

12. OO Relationships There are two kinds of Relationships
Generalization (parent-child relationship)
Association (student enrolls in course)
Associations can be further classified as
Aggregation
Composition

13. OO Relationships: Generalization
Supertype
Example:
Customer
Regular
Customer
Loyalty
Customer
Subtype1
Subtype2
-Inheritance is a required feature of object orientation
-Generalization expresses a parent/child relationship among related classes.
Used for abstracting details in several layers

14. OO Relationships: Association
Represent relationship between instances of classes
Student enrolls in a course
Courses have students
Courses have exams
Etc.
Association has two ends
Role names (e.g. enrolls)
Multiplicity (e.g. One course can have many students)
Navigability (unidirectional, bidirectional)

15. Multiplicity Indicators
Each end of an association or aggregation contains a multiplicity indicator
Indicates the number of objects participating in the relationship
Zero or more
0..*
One or more
1..*
Zero or one
0..1
Specified range
2..7
Exactly one 1

16. Association: Multiplicity and Roles
student 1 *
University
Person
0..1 *
teacher
employer
Role
Multiplicity
Symbol Meaning
1 One and only one
0..1 Zero or one
M..N From M to N (natural language)
* From zero to any positive integer
0..* From zero to any positive integer
1..* From one to any positive integer
Role
“A given university groups many people; some act as students, others as teachers. A given student belongs to a single university; a given teacher may or may not be working for the university at a particular time.”

17. Multiplicity Indicators

18. Class diagram
[from UML Distilled Third Edition]

19. Association: Model to Implementation* 4
Student
Course
has
enrolls
Class Student {
Course enrolls[4]; }
Class Course {
Student have[];

20. OO Relationships: Composition
Association
Models the part–whole relationship
Composition
Also models the part–whole relationship but, in addition, Every part may belong to only one whole, and If the whole is deleted, so are the parts
Example:
A number of different chess boards: Each square belongs to only one board. If a chess board is thrown away, all 64 squares on that board go as well.
Class W
Whole Class
Class P1
Class P2
Part Classes
[From Dr.David A. Workman]
Example
Figure 16.7
The McGraw-Hill Companies, 2005

21. OO Relationships: Aggregation
Container Class
Aggregation:
expresses a relationship among instances of related classes. It is a specific kind of Container-Containee relationship.
express a more informal relationship than composition expresses.
Aggregation is appropriate when Container and Containees have no special access privileges to each other.
Class C
AGGREGATION
Class E1
Class E2
Containee Classes
Example
Bag
Apples
Milk
[From Dr.David A. Workman]

22. Aggregation vs. Composition
Composition is really a strong form of association
components have only one owner
components cannot exist independent of their owner
components live or die with their owner
e.g. Each car has an engine that can not be shared with other cars.
Aggregations
may form "part of" the association, but may not be essential to it. They may also exist independent of the aggregate. e.g. Apples may exist independent of the bag.

23. Example: Secret Code program

24. Package Relationships

25. Class Relationships

26. About the next 2 slides…
The next slide shows how cardinalities are denoted in Rose.
The following slide is the class diagram example from before, but this time with cardinalities marked on the associations.

27. UML diagrams: use cases
A use case encodes a typical user interaction with the system. In particular, it:
captures some user-visible function.
achieves some concrete goal for the user.
A complete set of use cases largely defines the requirements for your system: everything the user can see, and would like to do.
The granularity of your use cases determines the number of them (for you system). A clear design depends on showing the right level of detail.
A use case maps actors to functions. The actors need not be people.

28. Use case examples, 1 (High-level use case for powerpoint.)

29. About the last example...
Although this is a valid use case for powerpoint, and it completely captures user interaction with powerpoint, it’s too vague to be useful.

30. Use case examples, 2 (Finer-grained use cases for powerpoint.)

31. About the last example...
The last example gives a more useful view of powerpoint (or any similar application).
The cases are vague, but they focus your attention the key features, and would help in developing a more detailed requirements specification.
It still doesn’t give enough information to characterize powerpoint, which could be specified with tens or hundreds of use cases (though doing so might not be very useful either).

32. Use case examples, 3 (Relationships in a news web site.)

33. About the last example...
The last is more complicated and realistic use case diagram. It captures several key use cases for the system.
Note the multiple actors. In particular, ‘AP wire’ is an actor, with an important interaction with the system, but is not a person (or even a computer system, necessarily).
The notes between << >> marks are stereotypes: identifiers added to make the diagram more informative. Here they differentiate between different roles (ie, different meanings of an arrow in this diagram).

34. Sequence Diagrams

35. Interaction Diagrams show how objects interact with one another
UML supports two types of interaction diagrams
Sequence diagrams
Collaboration diagrams

36. Sequence Diagram(make a phone call)
Caller
Phone
Recipient
Picks up
Dial tone
Dial
Ring notification
Ring
Picks up
Hello

37. Sequence Diagram:Object interaction
Synchronous
Asynchronous
Transmission delayed
Self-Call
[condition] remove()
*[for each] remove()
Self-Call: A message that an
Object sends to itself.
Condition: indicates when a message is sent. The message is sent only if the condition is true.
Condition
Iteration

38. Sequence Diagrams – Object Life Spans
Creation
Create message
Object life starts at that point
Activation
Symbolized by rectangular stripes
Place on the lifeline where object is activated.
Rectangle also denotes when object is deactivated.
Deletion
Placing an ‘X’ on lifeline
Object’s life ends at that point A B
Create X
Deletion
Return
Lifeline
Activation bar

39. Sequence Diagram
Message
Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass.
The horizontal dimension shows the objects participating in the interaction.
The vertical arrangement of messages indicates their order.
The labels may contain the seq. # to indicate concurrency.

40. Overview of UML Diagrams
Behavioral
: behavioral features of a system / business process
Activity
State machine
Use case
Interaction
Structural
: element of spec. irrespective of time
Class
Component
Deployment
Object
Composite structure
Package
Interaction
: emphasize object interaction
Communication(collaberati on)
Sequence
Interaction overview
Timing

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

42. Component diagram

43. Interaction Diagrams: Collaboration diagrams
start
6: remove reservation
3 : [not available] reserve title
User
Reservations
5: title available
6 : borrow title
1: look up
2: title data
4 : title returned
Catalog
5 : hold title
Collaboration diagrams are equivalent to sequence diagrams. All the features of sequence diagrams are equally applicable to collaboration diagrams
Use a sequence diagram when the transfer of information is the focus of attention
Use a collaboration diagram when concentrating on the classes

44. State Diagrams (Billing Example)
State Diagrams show the sequences of states an object goes through during its life cycle in response to stimuli, together with its responses and actions; an abstraction of all possible behaviors.
End
Start
Unpaid
Paid
Invoice created
paying
Invoice destroying

45. State Diagrams (Traffic light example)
Start
Traffic Light
State
Red
Transition
Yellow timer expires
Yellow
Car trips sensor
Green timer expires
Green
Event

46. UML diagrams: sequence diagram
Sequence diagram describe algorithms, though usually at a high level: the operations in a useful sequence diagram specify the “message passing” (method invocation) between objects (classes, roles) in the system.
The notation is based on each object’s life span, with message passing marked in time-order between the objects. Iteration and conditional operations may be specified.
May in principle be used at the same three levels as class diagrams, though the specification level will usually be most useful. (At the implementation level, you might better use pseudocode.)

47. Sequence diagram example

48. About the last example...
Each box with connected line represents a distinct thing, where all the things aren’t necessarily in the same piece of software, or software at all.
Arrows indicate message passing. That is, an arrow indicates that one thing tells another thing to do something.
Reverse arrows are implied. If arrow goes from A to B, and then immediately afterward an arrow goes from A to something else, it is understood that B completed it’s operation and returned control (and a result, probably) to A.
Time runs down the page. An comes before an arrow that is below it.
Bracketed expressions indicate conditions. In the diagram, an error document is returned if the fileLoad() operation returns and error.

49. About the next 3 slides…
The next several slides are about sequence diagrams (for algorithms, processes).
The next slide shows how to create a sequence diagram in browser, by associating it with a use case.
The following slide shows some “objects” in a sequence diagram, and the slide after shows how to associated an object with a class. Objects are a bit more general than classes, but you’ll get the best results if you create a one- to-one association between the objects in your sequence diagrams and the classes you’ve defined (define your classes first, if you can!).

50. Creating a Sequence Diagram

51. Representing Objects
Object
only
Class
only
Object and
Class
Actor

52. Assigning Objects to Classes
A new class can be created for the object
An object can be assigned to a class already defined

53. About the next 3 slides…
The next slide shows how to denote message passing in a sequence diagram. To pass a message is usually to call a method on an object.
The following slide shows a notation for “focus of control”. This means that an object in control when there is a box around its lifeline. The example indicates that “Student” maintains control throughout “drop a course”, even while “Maintain schedule form” does its thing. Among other things, this can be used to imply that called methods terminate and return.
The third slide shows a full sequence diagram example.

54. Messages

55. Focus of Control

56. Exercise: Sequence Diagram

57. UML diagrams: Package diagram
A type of class diagram, package diagrams show dependencies between high-level system component.
A “package” is usually a collection of related classes, and will usually be specified by it’s own class diagram.
The software in two distinct packages is separate; packages only interact through well-defined interfaces, there is no direct sharing of data or code.
Not all packages in a system’s package diagram are new software; many packages (components) in a complex system are often already available as existing or off-the- shelf software.

58. Package diagram example

59. About the last example... This package diagram indicates that:
there are three dependent but decoupled software components that will be developed in “My Project”, which is itself a package or component.
Parts of my software depend on some existing software packages, which I won’t be developing, but just using (“Webserver” and “Database”).
There is a globally available package “User authentication” which all the other packages depend on.

60. About the next slide…
The next slide shows a complete deployment diagram.
A deployment diagram is useful for showing how your software will be deployed on hardware. It may show how your system will integrate with existing systems in the domain.

61. Exercise: Deployment Diagram

62. UML diagram hierarchy

63. Use Case diagram to Class Diagram

64. Use Case diagram to Class Diagram

65. Use Case diagram to Class Diagram: contd

66. Adapter

67. Composite

68. Facade

69. Proxy

70. UML tools
Rational Rose is the “real world” standard; full round- trip code generation
Recently acquired by IBM (right under Microsoft’s nose!)
Together (from Borland) is a lot like Rational Rose
I haven’t used it in about three years (since before Borland bought it from TogetherSoft)
ArgoUML looks interesting (and is open source)
BlueJ, of course, displays simple UML diagrams
Drawing programs with UML support
Visio is a Microsoft tool
Dia is a freeware clone of Visio

71. Tool links Rational Rose Together ArgoUML Visio Dia
Together
ArgoUML
Visio
Hard to find info on Microsoft’s site!
Dia

72. The End