1. UML Notations in CommonKADS Activity diagrams State diagrams Class diagrams Use-case diagrams

2. UML notations 2 Background UML n Nineties: number of popular object-oriented methods n Unified Modeling Language: proposal for set of standard notations n wide attention ä see www.rational.com n mainly meant for analysis phase

3. UML notations 3 UML notations used n Class diagram ä static information structure (“data”) n Activity diagram ä combined function/control view n Use-case diagram ä high level view of system services (functional) n State diagram ä highly interactive control

4. UML notations 4 Activity diagram n Model control and information flow of a procedure or process n Useful if control is mainly synchronous ä otherwise: use state diagram n Use in CommonKADS: modeling the organizational process ä worksheet OM-2 of the organization model n Can also be used to model control flow within a task method (knowledge model)

5. UML notations 5 Action state n State in which some work is being done ä activity, task n State terminates when the work is finished ä difference with state diagrams n After termination the action state can lead to another action state ä “state transition” n Special symbols for being and end of a procedure or process

6. UML notations 6 Basic notation for activity diagram

7. UML notations 7 Decision n Sate transition is deterministic n If transition depends on outcome of the work, then introduce a decision

8. UML notations 8 Introducing concurrency

9. UML notations 9 Swim lanes n Process can sometimes be distributed over several agents or organizational units n Notation: use compartments n In particular useful when modeling a business process (e.g. in organization model)

10. UML notations 10 Notation for swim lanes

11. UML notations 11 Object flow

12. UML notations 12 Signals

13. UML notations 13 Business process “Housing”

14. UML notations 14 Activity diagram of method control

15. UML notations 15 State diagrams n Synonyms: “state chart”, “state-transition diagram” n Purpose: model of dynamic behavior n Use if control is heavily influenced by “external” events n Draw a state diagram for object classes with interesting behavior n Activity diagram is alternative ä internal control ä object flow

16. UML notations 16 State

17. UML notations 17 State transition n Event: comes from outside the object modeled n Message: generates event for another object n Guard: outcome of internal object computation

18. UML notations 18 Actions and activities n Action: instantaneous, not interruptible ä on transition ä on state entry = action on all incoming transitions ä on state exit = action on all outgoing transitions ä on event n Activity: takes time, interruptible

19. UML notations 19 State diagram of ticket machine

20. UML notations 20 State concurrency

21. UML notations 21 State generalization n If Object A is in super-state S, then the object us in precisely one of the sub-states n Cf. concurrency: “and”-states

22. UML notations 22 State diagrams in CommonKADS n Communication modeling (Ch. 8) n Asynchronous reasoning control ä real-time applications n Control specification for the business process n Overlap with activity diagrams ä state with no outgoing events = action state

23. UML notations 23 State diagram “Housing”

24. UML notations 24 Class diagram n Captures static information structure ä In O-O: also functions n Generalization, inheritance & reuse are important issues n Imported into CommonKADS domain- schema notation ä no use made of operation box n Can also be used in Task Model to sketch task information structure

25. UML notations 25 Objects and classes

26. UML notations 26 Object class n Describes a group of objects with similar properties ä Abbreviation: "class" n Rationale for introducing classes: ä it provides a means for abstraction n Terminology: “object” is often used in an ambiguous way, pointing to both objects (in the strict sense) and object classes.

27. UML notations 27 Attributes n An attribute describes a value held by objects belonging to the class. n Attribute specification consists of: ä Class it is defined on (student) ä Attribute name (name) ä Admissible values (string) ä Optional: default value

28. UML notations 28 Object and Value n Most O-O approaches distinguish between objects and values. n Difference: a value does not have an identity ä it "lives” only in connection to a certain object. n RULE 1: an object is not allowed as a possible value of an attribute! n RULE 2: attribute names need only to be unique within a class.

29. UML notations 29 Values and Value Sets n Values are the primitive things with no internal structure from the viewpoint of the application n Admissible values are defined through a value set n Typical predefined value-sets: ä string, number, integer, real, range, boolean, …. n User-defined: ä set or list of strings

30. UML notations 30 Object Identifiers n In O-O modeling you assume that every object has an identity. n Consequence: introduce only attributes that act as identifiers, iff the identifier is something that exists in the real world. n Examples: student card number, social security number.

31. UML notations 31 Operations n Definition: ä operation is "a function or a transformation that can be applied to objects of a class". n Objects in a class share the same operations. n Method: implementation of an operation n = functional view

32. UML notations 32 Class notation

33. UML notations 33 Associations n Associations are used to link objects to other objects n Majority of associations: ä binary (between two objects) ä directional (should be read in a particular direction n Ternary associations come up occasionally. n Associations between more than three objects are rare.

34. UML notations 34 Association notation

35. UML notations 35 Multiplicity examples

36. UML notations 36 Multiplicity n Also called: "cardinality". n Always connected to one of the classes involved. n Typical types of multiplicity: ä 0-1Zero or one (optional). ä 1Precisely one. ä 0+ Zero or more, ä 1+One or more.

37. UML notations 37 Association class n Modeling an association as a class if the association has an internal information structure n Advantage: associations become first-class objects. n Attributes and methods can be defined for the association class.

38. UML notations 38 Notation association class

39. UML notations 39 Use of an association class

40. UML notations 40 Associations with specific semantics n Associations provide a general, "neutral", way of connecting object classes. n Semantics of the association are defined through argument typing, multiplicity and (implicitly) the name of the association. n Class diagrams provide specific types of associations, with predefined semantics: ä generalization ("is a"). ä aggregation ("part of").

41. UML notations 41 Generalization n Purpose: sharing similarities while preserving differences n Is an association between a class that acts as super- class and one or more classes called the sub- classes. n Super-classes show the features that the sub-classes have in common. n Each sub-class inherits the attributes and operations defined on its super-class(es).

42. UML notations 42 Notation for generalization

43. UML notations 43 Aggregation n Aggregation denotes a binary association in which one side is an "assembly" and the other side a "part". n "Assembly" and "part" act as predefined roles involved in the aggregation association. n Cardinality of a part can be defined ä precisely one; optional (0-1); many,...

44. UML notations 44 Notation for aggregation

45. UML notations 45 Composition n Sub-type of aggregation n Existence of part depends on aggregate

46. UML notations 46 Aggregation and generalization n Similarities: ä Tree-like structure ä Transitive properties n Differences: ä AND-tree (aggregation) vs. OR-tree (generalization) ä instance tree (aggregation) vs. class tree (generalization)

47. UML notations 47 Combined aggregation and generalization

48. UML notations 48 Use-case diagram n shows services that can be expected from a system n provides outsider view (customer) n terminology use caseservice provided by system actoragent using a system service n used in early phases of system analysis n use in CommonKADS: way to present possible solutions to customer

49. UML notations 49 Use cases for a library

50. UML notations 50 A small case study n Course administration system (CAS) n Context: university department n Required services: STUDENT: update personal data, inspect exam results, inspect course info, enroll in course TUTOR: inspect exam results, update course info, inspect enrollments ADMIN STAFF: enter exam results, inspect exam results, update personal data students, inspect enrollments

51. UML notations 51 Use cases

52. UML notations 52 Class diagram student student-card#: string name: string address: string date-of-birth: data major: Major......... course course-code: string year: integer trimester: 1-3 study-points: integer learning-goals: string description: text literature: text maximum-#students: integer exam date: date result: [0..10] enrollment date: date university staff member title: string position: string department: string telephone: string room: string e-mail: string 0+ course-exam 1 0+ tutor 0+ 1+ 0+ requires

53. UML notations 53 Activity diagram for course enrollment procedure

54. UML notations 54 State diagram: “update student data”