UML Notations in CommonKADS

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

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

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

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

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

6. Basic notation for activity diagram

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

8. Introducing concurrency

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

10. Notation for swim lanes

11. Object flow

12. Signals

13. Business process “Housing”

14. Activity diagram of method control

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

16. State

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

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

19. State diagram of ticket machine

20. State concurrency

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

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

23. State diagram “Housing”

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

25. Objects and classes

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

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

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

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

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

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

32. Class notation

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

34. Association notation

35. Multiplicity examples

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

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

38. Notation association class

39. Use of an association class

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

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

42. Notation for generalization

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

44. Notation for aggregation

45. Composition • Sub-type of aggregation • Existence of part depends on aggregate

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

47. Combined aggregation and generalization

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

49. Use cases for a library

50. A small case study • Course administration system (CAS) • Context: university department • 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