1. The What, Why and How of the UML Collaboration
Tutorial J3, TOOLS 2000
8 June 2000
Trygve
Mogul Norge AS, Oslo
The What, Why and How of the UML Collaboration

2. Legal Notice This presentation is copyright
Understand IT
Wednesday, January 02, 2019
Legal Notice
This presentation is copyright
©2000 Trygve Reenskaug Oslo, Norway.
All rights reserved.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made for profit or commercial advantage and that copies bear this notice and full citation on the first page.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

3. Activity network planning Our main example
Understand IT
Wednesday, January 02, 2019
Activity network planning Our main example
The (toy) sample user interface is a Java Applet that is run from a web browser. The interface interacts with a background service that is also written in Java.
The top bars in the bar chart shows the earliest times when the activities can be performed. The bottom bars show when the activities all have to be done by the same resource, and this resource can only serve one activity at the time.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

4. The Idea: Records --> Objects Some relevant shipyard objects
Understand IT
Wednesday, January 02, 2019
Object representing
the Shipyard
Object representing a ship’s schedule
Object representing
the shipyard resources
Object representing
a construction activity
Object representing
a resource
Our example is taken from a shipyard. We represent important aspects by objects and let work scheduling be performed through negotiation between these objects.
Object representing
a ship's part
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

5. What we need to achieve Lay a course to intercept the future
Where we
want to go
Opportunistic
path of evolution
Lay course to intercept
the future
We are here
Two key issues:
Vision
Technology
The What, Why and How of the UML Collaboration

6. Lay a course to intercept the future Where we want to go
Vast Complexity
Transparent & Comprehensible
Participatory & Graduated knowledge
Support Human Communication
Multiple Owners
Interoperability
Geographic Distribution
Heterogeneous Platforms
·····
The What, Why and How of the UML Collaboration

7. Lay a course to intercept the future Existing technology
Objects
Vast Complexity
Transparent & Comprehensible
Participatory & Graduated knowledge
Support Human Communication
Multiple Owners
CORBA
Interoperability
Geographic Distribution
Heterogeneous Platforms
Master complexity
Acceptable quality
·····
The What, Why and How of the UML Collaboration

8. The OMG vision: A Universe of objects
The What, Why and How of the UML Collaboration

9. CORBA Controls the Interfaces
IDL : messages
XML : information
The What, Why and How of the UML Collaboration

10. A system is a chosen perspective on reality
A system is a part of the real world which we choose to regard as a whole,
separated from the rest of the world during some period of consideration.
A whole that we choose to consider as a collection of parts,
each part being characterized by attributes and by actions which may involve itself and other parts.
Holbæk_Hanssen et.al.: System Description and the Delta Language
Oslo, 1977
The What, Why and How of the UML Collaboration

11. Consider the Universe as a Universe of objects
The What, Why and How of the UML Collaboration

12. An Open System For a given system,
the environment is the set of all objects outside the system
who affect the system
or who are affected by the system.
Etzioni: Modern Organizations
Prentice-Hall, 1964
The What, Why and How of the UML Collaboration

13. Open systems interact with environment objects
The What, Why and How of the UML Collaboration

14. The UML collaboration Tutorial Plan Introduction
Typing AssociationEndRoles specifies classes.
Specialization of a collaboration
System behavior, messages and interfaces
Information hiding & component technology
Summary and conclusion
The What, Why and How of the UML Collaboration

15. The UML instance level collaboration models a system of objects
The What, Why and How of the UML Collaboration

16. The UML Collaboration is a powerful tool
for Modeling system behavior.
for Enterprise modeling
for Distributed system design
for System architecture at all levels
for Designing the details of an OO program.
for Tracing requirements between different levels of abstractions
The What, Why and How of the UML Collaboration

17. A conceptual model implies choice of mode of thinking
A model is never complete
A model focuses on essentials
A model hides inessentials
A model reflects a CHOICE Choice of language critical
A productive way of thinking is supported by a good choice of modeling language
The What, Why and How of the UML Collaboration

18. UML Two powerful abstractions
Understand IT
Wednesday, January 02, 2019
UML Two powerful abstractions
Class abstraction
Models system construction
Collaboration abstraction
Models system behavior
UML
Object
Oriented
Modeling
UML is a very rich modeling language, encompassing most important object oriented modeling paradigms that have been proposed over the past years.
We will focus on the four important abstractions that are illustrated in the slide.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

19. The UML class abstraction The UML collaboration abstraction
Objects are encapsulations of data and behavior. Objects are encapsulations of data and behavior.
Objects are instances of classes. An object has a unique identity.
Associations between two or more classes specify links between their instances. An object collaborates with other objects by message interaction.
An operation describes a service that can be requested from an object to effect behavior. The visible behavior consists its input and output interfaces.
The What, Why and How of the UML Collaboration

20. The Object as seen by the Collaboration
Object B
Object A
Message
triggers method
causes response
Port
toB
TO-B IN
Message
TO-C
toC IN
TO-C
toC
Message
Object C
Methods
Variables
Methods
Variables IN
Methods
Variables
The What, Why and How of the UML Collaboration

21. An instance level collaboration
Bjarne
Gina
father
mother
Trygve
The What, Why and How of the UML Collaboration

22. An instance level sequence diagram
Trygve
Gina
cashRequest($25)
cashReceived($25)
The What, Why and How of the UML Collaboration

23. Collaboration definition
A Collaboration describes how a number of objects work together for a common purpose.
What are the objects ?
What are the responsibilities of each object in the context of the collaboration purpose ?
What are the links that connect the objects into a communicating whole ?
How are messages flowing between the objects to achieve the common purpose ?
The What, Why and How of the UML Collaboration

24. Exercise Make your own object structure
Describe a number of objects that work together.
Purpose: to run an e-bookshop.
What are the objects ?
What are their responsibilities ?
What are the links that connect them ?
How are messages flowing between the objects?
The What, Why and How of the UML Collaboration

25. Activity network planning Our main example
Understand IT
Wednesday, January 02, 2019
Activity network planning Our main example
The (toy) sample user interface is a Java Applet that is run from a web browser. The interface interacts with a background service that is also written in Java.
The top bars in the bar chart shows the earliest times when the activities can be performed. The bottom bars show when the activities all have to be done by the same resource, and this resource can only serve one activity at the time.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

26. Exercise The example Activity Network
Activity-B
7 (4) 10
Activity-D
14 (3) 16
Activity-A
1 (6) 6
Activity-F
18 (2) 19
Activity-C
7 (7) 13
Activity-E
14 (4) 17
Duration
Completion time
Start time
What are the objects?
The What, Why and How of the UML Collaboration

27. The example Activity Network Objects and Interaction
fL(t) =
public void
frontLoad (int time )
Project
1:fL(0)
9:fL(19)
Activity-B
7 (4) 10
Activity-D
14 (3) 16
4:fL(10)
2:fL(6)
7:fL(16)
Activity-A
1 (6) 6
Activity-F
18 (2) 19
5:fL(13)
3:fL(6)
Activity-C
7 (7) 13
Activity-E
14 (4) 17
8:fL(17)
6:fL(13)
The What, Why and How of the UML Collaboration

28. The example Activity Network Message Sequence Chart
Project
Activity -A
Activity -B
Activity -C
Activity -D
Activity -E
Activity -F
fL(0)
fL(6)
fL(6)
fL(10)
fL(13)
fL(13)
fL(16)
fL(17)
fL(19)
The What, Why and How of the UML Collaboration

29. Essential questions answered by the Collaboration
What is the purpose ?
What are the objects ?
What are their responsibilities ?
How are they interconnected ?
How do they interact ?
The What, Why and How of the UML Collaboration

30. Specification level collaboration ClassifierRole definition
A ClassifierRole is a named slot for an object participating in a Collaboration.
Object behavior is represented by its participation in the overall behavior of the Collaboration.
Object identity is preserved through this constraint:
"In an instance of a collaboration, each ClassifierRole maps onto at most one object."
The What, Why and How of the UML Collaboration

31. Specification level collaboration a simple example
/ Father
/ Mother 1
father 1
mother
1: cashRequest(amount)
2. cashReceived(amount) * *
/ Child
The What, Why and How of the UML Collaboration

32. A specification level sequence diagram
/ Child
/ Mother
cashRequest(amount)
cashReceived(amount)
The What, Why and How of the UML Collaboration

33. Specification level Collaboration Frontloading Use Case
Understand IT
Wednesday, January 02, 2019
Specification level Collaboration Frontloading Use Case
/ F-Pred
/ F-Act
/ F-Succ
fL(t1)
fL(t2)
"In an instance of a collaboration, each ClassifierRole maps onto at most one object.”
A many-relation (*) means that the role represents a typical member of the set All other members behave correspondingly *
We change our perspective from classes to objects; from sets to individuals. This permits us to study patterns of interacting objects: What are the objects, what are their responsibilities, and how do their collaborate to achieve the system functionality.
The role represents the object’s position in the structure. We see that instances of the Activity class play different roles: Predecessor, Activity, and Successor. Instances of the Project class are also Predecessors, in this way a Project can start the frontloading operation. The Project also plays the Successor role so that it can receive the final scheduling messages.
We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

34. What roles are the objects playing?
Predecessor
Project
Activity
/Predecessor
/Successor
Successor
Activity-B
Activity-D
/Predecessor
/Activity
/Successor
Activity-A
Activity-F
Activity-C
Activity-E
The What, Why and How of the UML Collaboration

35. Specification level Collaboration Frontloading Sequence Diagram
Understand IT
Wednesday, January 02, 2019
Specification level Collaboration Frontloading Sequence Diagram
/ F-Pred
/ F-Act
/ F-Succ
fL(t1)
fL(t2)
A collaboration (role model) represents a pattern of objects that interact to perform a given use case in order to reach a specified goal.
The scenario is one way of describing the dynamics of interacting objects.
Note that the nodes of a scenario cannot be classes, because the classes hide object identity and we cannot know which object sends and which object receives the messages.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

36. Typing AssociationEndRoles specifies classes.
Tutorial Plan
Introduction
The UML collaboration
Typing AssociationEndRoles specifies classes.
Specialization of a collaboration
System behavior, messages and interfaces
Information hiding & component technology
Summary and conclusion
The What, Why and How of the UML Collaboration

37. Typing the out baskets (AssociationEndRoles)
/ Father
/ Mother
father
mother
«Interface»
Child_to_Mother
cashRequested(amount)
«Interface»
Mother_to_Child
cashReceived(amount)
/ Child
The What, Why and How of the UML Collaboration

38. Typing the out baskets “Lollipop Notation”
/ Father
/ Mother
«Interface»
Mother_to_Child
cashReceived(amount)
«Interface»
Child_to_Mother
cashRequested(amount)
/ Child
The What, Why and How of the UML Collaboration

39. Interfaces in the Basic scheduling collaboration
Understand IT
Wednesday, January 02, 2019
Interfaces in the Basic scheduling collaboration
The interfaces specify minimal requirements
to receiving classes
/ F-Pred
/ F-Act
/ F-Succ
«Interface»
Backload
backLoad(t)
«Interface»
Frontload
frontLoad(t)
We change our perspective from classes to objects; from sets to individuals. This permits us to study patterns of interacting objects: What are the objects, what are their responsibilities, and how do their collaborate to achieve the system functionality.
The role represents the object’s position in the structure. We see that instances of the Activity class play different roles: Predecessor, Activity, and Successor. Instances of the Project class are also Predecessors, in this way a Project can start the frontloading operation. The Project also plays the Successor role so that it can receive the final scheduling messages.
We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

40. Possible implementations of the Basic scheduling collaboration
Understand IT
Wednesday, January 02, 2019
Possible implementations of the Basic scheduling collaboration
The interfaces specify minimal requirements
to receiving classes
/ F-Pred
:Activity, Project
/ F-Act
:Activity
/ F-Succ
/ Predecessor
/ Activity
/ Succcessor
«Interface»
Backload
backLoad(t)
backLoad(t)
frontLoad(t)
backLoad(t)
frontLoad(t)
«Interface»
Frontload
frontLoad(t)
We change our perspective from classes to objects; from sets to individuals. This permits us to study patterns of interacting objects: What are the objects, what are their responsibilities, and how do their collaborate to achieve the system functionality.
The role represents the object’s position in the structure. We see that instances of the Activity class play different roles: Predecessor, Activity, and Successor. Instances of the Project class are also Predecessors, in this way a Project can start the frontloading operation. The Project also plays the Successor role so that it can receive the final scheduling messages.
We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

41. Exercise: Define class Activity in your favourite language
Understand IT
Wednesday, January 02, 2019
Exercise: Define class Activity in your favourite language
The interfaces specify minimal requirements
to receiving classes
/ F-Pred
:Activity, Project
/ F-Act
:Activity
/ F-Succ
/ Predecessor
/ Activity
/ Succcessor
«Interface»
Backload
backLoad(t)
backLoad(t)
frontLoad(t)
backLoad(t)
frontLoad(t)
«Interface»
Frontload
frontLoad(t)
We change our perspective from classes to objects; from sets to individuals. This permits us to study patterns of interacting objects: What are the objects, what are their responsibilities, and how do their collaborate to achieve the system functionality.
The role represents the object’s position in the structure. We see that instances of the Activity class play different roles: Predecessor, Activity, and Successor. Instances of the Project class are also Predecessors, in this way a Project can start the frontloading operation. The Project also plays the Successor role so that it can receive the final scheduling messages.
We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

42. Enterprise Java Bean Application Assembler perspective
Information Bus
/ WEB
Browser
/ Name
Server
/ Applet (End user tool)
1: lookup("roombroker");
/ Booking
Home
Factory object
/ Booking Bean
/ Booking
Object
2: create(xxx);
3: ejbCreate(xxx);
4: getRooms();
/ Room Chooser
Java Beans
5: getRooms();
6: addItem(element)
The What, Why and How of the UML Collaboration

43. Highlight Collaboration Hide implementation
Information Bus
/ WEB
Browser
/ Name
Server
The object
has responsibility
knows its collaborators
is robust
Nobody knows everything!
/ Applet (End user tool)
Code is
invisible!
1: lookup("roombroker");
/ Booking
Home
Factory object
/ Booking Bean
/ Booking
Object
2: create(xxx);
3: ejbCreate(xxx);
4: getRooms();
Objects References Interfaces
are visible!
/ Room Chooser
Java Beans
5: getRooms();
6: addItem(element)
The What, Why and How of the UML Collaboration

44. Specialization of a collaboration
Tutorial Plan
Introduction
The UML collaboration
Typing AssociationEndRoles specifies classes.
Specialization of a collaboration
System behavior, messages and interfaces
Information hiding & component technology
Summary and conclusion
The What, Why and How of the UML Collaboration

45. Generalization of Collaborations OOram Synthesis
Collaboration for Use case / operation Use Case 1
Collaboration for Use case / operation Use Case 2
Object
Object
Object
Object A B C D
The What, Why and How of the UML Collaboration

46. Example illustrating the definition
/Leaf
/Node
/Root 1 *
/SuperNode 1 *
/SubNode
The What, Why and How of the UML Collaboration

47. Planning Network with Resources
Understand IT
Wednesday, January 02, 2019
Planning Network with Resources
An example of specialization: Some activities use a Gantry crane. Our crane has two independent hooks: One can lift a light load and the other can lift any load.
Activity B is to lift a light load. It can be performed concurrently with activity C, which is a heavy load. Activities D and E are both heavy loads, they have to be performed in sequence. Activities A and F use the old resource that can serve one at the time.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

48. Exercise Activity planning with resources
Use Cases:
Frontloading
Resource allocation for single activity
For last use case:
What are the objects ?
What are their responsibilities ?
How are they interconnected ?
How do they interact ?
The What, Why and How of the UML Collaboration

49. Activity planning Resource Allocation Use Case
Understand IT
Wednesday, January 02, 2019
Activity planning Resource Allocation Use Case
alloc() = public void allocate (Activity act, int earlyStart, int duration)
reserv() = public void reserved (int start, int end)
/ R-Act *
1: alloc()
2: reserv() 1
We change our perspective from classes to objects; from sets to individuals. This permits us to study patterns of interacting objects: What are the objects, what are their responsibilities, and how do their collaborate to achieve the system functionality.
The role represents the object’s position in the structure. We see that instances of the Activity class play different roles: Predecessor, Activity, and Successor. Instances of the Project class are also Predecessors, in this way a Project can start the frontloading operation. The Project also plays the Successor role so that it can receive the final scheduling messages.
We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties.
/ R-Res
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

50. Specialization of Collaboration Frontloading with resources
Understand IT
Wednesday, January 02, 2019
Specialization of Collaboration Frontloading with resources
/ F-Pred
/ F-Act
/ F-Succ
1: fL(t1)
2: fL(t2) * * *
/ C-Pred
/ Activity
/ C-Succ
Synthesized model
1: fL(t1)
2: fL(t2) 1 *
/ C-Res
/ C-Act
1.1: alloc()
1.2: reserv() 1 *
/ R-Res
/ R-Act 2:
reserv() 1:
alloc()
We change our perspective from classes to objects; from sets to individuals. This permits us to study patterns of interacting objects: What are the objects, what are their responsibilities, and how do their collaborate to achieve the system functionality.
The role represents the object’s position in the structure. We see that instances of the Activity class play different roles: Predecessor, Activity, and Successor. Instances of the Project class are also Predecessors, in this way a Project can start the frontloading operation. The Project also plays the Successor role so that it can receive the final scheduling messages.
We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

51. Exercise: Specialization of Classes
Understand IT
Wednesday, January 02, 2019
Exercise: Specialization of Classes
1: fL(t1)
2: fL(t2)
classes FActivity and RActivity exist
Define class CActivity
/ F-Pred
/ F-Act
: FActivity
/ F-Succ * *
Synthesized model
1: fL(t1)
2: fL(t2)
/ C-Pred
/ C-Act
: CActivity
/ Activity
/ C-Succ * * 1
1.1: alloc()
1.2: reserv()
/ R-Act
: RActivity *
We change our perspective from classes to objects; from sets to individuals. This permits us to study patterns of interacting objects: What are the objects, what are their responsibilities, and how do their collaborate to achieve the system functionality.
The role represents the object’s position in the structure. We see that instances of the Activity class play different roles: Predecessor, Activity, and Successor. Instances of the Project class are also Predecessors, in this way a Project can start the frontloading operation. The Project also plays the Successor role so that it can receive the final scheduling messages.
We achieve a separation of concern; a collaboration describes the objects involved in one or more functions, describing the objects involved only and focusing on the relevant object properties.
/ C-Res 1 1:
alloc() 2:
reserv() *
/ R-Res
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

52. System behavior, messages and interfaces
Tutorial Plan
Introduction
The UML collaboration
Typing AssociationEndRoles specifies classes.
Specialization of a collaboration
System behavior, messages and interfaces
Information hiding & component technology
Summary and conclusion
The What, Why and How of the UML Collaboration

53. Role and system behavior The Collaboration
/ File
start() 1
read()
write()
stop() 1
/ Master 1
fileStarted()
runCompleted()
fileStopped() 1 *
/ Slave *
run()
The What, Why and How of the UML Collaboration

54. Role and system behavior Sequence Diagram
/Master
/File
/Slave
start()
fileStarted()
run()
read()
readDone()
write()
writeDone()
runCompleted()
stop()
fileStopped()
The What, Why and How of the UML Collaboration

55. Role and system behavior Role State Machines
Slave.readDone();
Idle
start/
open file;
master.fileStarted();
Ready
stop
/closeFile;
Master.fileStopped();
/ File
Done
Initial
read
/read();
write
/write();
Slave.writeDone();
Stopping
WaitComplete
WaitStart
/ Master
Initial/File.start();
fileStarted
/Slave.run();
runCompleted
/File.stop();
fileStopped
final
Idle
done
Editing
run/File.read();
writeDone
/Master.runCompleted();
readDone
/File.write();
/ Slave
Initial
The What, Why and How of the UML Collaboration

56. Role and system behavior System State Machine
Initial->File.start();
Master-WaitStart & File-Idle & Slave-Idle
File start / open file; Master.fileStarted;
Master-WaitStart &
File-Ready
& Slave-Idle
Master fileStarted / Slave.run();
Master-WaitComplete
& File-Ready & Slave-Idle
Slave run / File.read()
Master-WaitComplete & File-Ready &
Slave-Editing
The What, Why and How of the UML Collaboration

57. Information hiding & component technology
Tutorial Plan
Introduction
The UML collaboration
Typing AssociationEndRoles specifies classes.
Specialization of a collaboration
System behavior, messages and interfaces
Information hiding & component technology
Summary and conclusion
The What, Why and How of the UML Collaboration

58. Make IT so simple that even a programmer can understand IT
Edsger Dijkstra:
Testing can only show the presence of bugs
Testing can never show the absence of bugs
The number of bugs in the system when you deliver it is proportional to the number of bugs found during testing
The only way to avoid bugs is not to put them in in the first place
I.E., Keep It Simple And Stupid (KISS)
bugs removed from Windows2000 during testing
The What, Why and How of the UML Collaboration

59. Separation of Concerns Two object-oriented techniques
Understand IT
Wednesday, January 02, 2019
Separation of Concerns Two object-oriented techniques
Components separate on services. A component offers certain services (operations) to its clients while it hides the realizations of these services.
Collaborations separate on system behavior. A collaboration model describes how slices of selected objects realize use cases.
We will explore three tec hniques for separation of concern that are more or less available in UML:
Filtered class diagrams offer unspecified separation. A class diagram can show a filtered view of an arbitrary selection of classes. (¤ Every time a word coinciding with the name of some construct in UML is used, that construct is referenced.)
omponents separate on services. A component offers certain services (operations) to its clients while it hides the realizations of these services.
Collaborations separate on system behavior. One collaboration model describes how a system of interacting components realize one or more operations or use cases.
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

60. Horizontal Separation of concern Cluster objects into “super-objects”
The (EJB) Component ~~ UML Subsystem:
A Component has a single access point (an object ID) and offers a well-defined interface to its clients.
A Component is reused by cloning
A Component does not make assumptions about its clients
A Component plays a standardized role within a container
Tools are used to deploy components and compose systems
Components can contain components
The What, Why and How of the UML Collaboration

61. Horizontal Separation of Concern Object clustering
«EJB»
BeanExample
UML 1.3 Subsystem
The What, Why and How of the UML Collaboration

62. Vertical Separation of Concern Collaborations separate on behavior
Collaboration for Use case / operation Use Case 1
Collaboration for Use case / operation Use Case 2
Object
Object
Object
Object A B C D
The What, Why and How of the UML Collaboration

63. Virtual Roles Four designs
/ViewPackage
«virtualRole»
/ModelPackage
/ ProjectView
/ ProjectModel * 1
/ ActivityView 1 *
/ ActivityModel 1 * * 1
The What, Why and How of the UML Collaboration

64. xxxxxxxxxxxxxxxx / ProjectView / ProjectModel * 1 1 1 * *
«virtualRole»
/ViewPackage
«virtualRole»
/ModelPackage
/ ProjectView
/ ProjectModel * 1 1 1 * *
/ ActivityView
/ ActivityModel
The What, Why and How of the UML Collaboration

65. UML Use Case Actors models environment objects
The What, Why and How of the UML Collaboration

66. VirtualRoles Use Case system
Function
Actor
The What, Why and How of the UML Collaboration

67. Virtual Interactions - transfer information to view
- alert view of changes in model
«virtualRole»
«virtualRole»
/ View
/ Model
The What, Why and How of the UML Collaboration

68. Virtual Interactions a la Catalysis
- transfer information to view
- alert view of changes in model
«virtualRole»
«virtualRole»
/ View
/ Model
The What, Why and How of the UML Collaboration

69. Summary and conclusion
Tutorial Plan
Introduction
The UML collaboration
Typing AssociationEndRoles specifies classes.
Specialization of a collaboration
System behavior, messages and interfaces
Information hiding & component technology
Summary and conclusion
The What, Why and How of the UML Collaboration

70. Four Concepts Classifier Object represents Role instantiates specifies
implements
Interface
The What, Why and How of the UML Collaboration

71. To sum up Collaborations specify system behavior
Collaborations model system at run-time Community of interacting objects
Collaborations model open systems Environment and core roles
ClassifierRole defined in terms of Collaboration instance "In an instance of a collaboration, each ClassifierRole maps onto at most one object." Roles are not types, but can be typed
Separation of concern: Decomposition of roles
Horizontal: component --> UML Subsystem
VirtualRole: UML package of ClassifierRole
Vertical: Use Case --> Collaboration
Virtual Interaction: UML Comment
The What, Why and How of the UML Collaboration

72. Make IT so simple that even a programmer can understand IT
Edsger Dijkstra:
Testing can only show the presence of bugs
Testing can never show the absence of bugs
The number of bugs in the system when you deliver it is proportional to the number of bugs found during testing
The only way to avoid bugs is not to put them in in the first place
IBM: Keep It Simple And Stupid (KISS)
bugs removed from Windows2000 during testing
The What, Why and How of the UML Collaboration

73. What is a Component ? Object pluggable on a backplane
Objects
Collaboration paths
Backplane (Container)
Net
Hardware
Operating System
Thanks to Øystein Myhre for this illustration
The What, Why and How of the UML Collaboration

74. Example: Reuse language component
spell check
and
grammar
Word
processor
New Order entry system
with a text field
The What, Why and How of the UML Collaboration

75. Make IT simple so that Programmers and Users can master it
Focus on:
Objects !
Responsibilities !
Message paths !
Interfaces !
Collaborations !
Invisible:
Code
Communication
etc.
Challenge: Manage complexity Solution: Objects & Collaborations
The What, Why and How of the UML Collaboration

76. Understand IT
Wednesday, January 02, 2019
More details ….
where I work with an example development also see "documents", particularly "UML Collaboration and OOram semantics"
Reenskaug, Wold, Lehne: Working With Objects. Manning/Prentice Hall ISBN The reference work (out of print)
Egil P. Andersen: Conceptual Modeling of Objects. A Role Modeling Approach. Dr Scient thesis. Dept. of Informatics, University of Oslo. 4 November The theory of role modeling ftp://ftp.nr.no/pub/egil/ConceptualModelingOO.ps.gz
Trygve Reenskaug : Working with objects: A three-model architecture for the analysis of information systems. JOOP May 1997.
Unified Modeling Language (UML). Object Management Group. Version 1.3, September 1, Document numbers through define version 1.1 (versions 1.2 and 1.3 under development):
The What, Why and How of the UML Collaboration
©2000 Trygve Reenskaug

77. The What, Why and How of the UML Collaboration