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

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 n mainly meant for analysis phase

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

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)

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

UML notations 6 Basic notation for activity diagram

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

UML notations 8 Introducing concurrency

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)

UML notations 10 Notation for swim lanes

UML notations 11 Object flow

UML notations 12 Signals

UML notations 13 Business process “Housing”

UML notations 14 Activity diagram of method control

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

UML notations 16 State

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

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

UML notations 19 State diagram of ticket machine

UML notations 20 State concurrency

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

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

UML notations 23 State diagram “Housing”

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

UML notations 25 Objects and classes

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.

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

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.

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

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.

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

UML notations 32 Class notation

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.

UML notations 34 Association notation

UML notations 35 Multiplicity examples

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.

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.

UML notations 38 Notation association class

UML notations 39 Use of an association class

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").

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

UML notations 42 Notation for generalization

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

UML notations 44 Notation for aggregation

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

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)

UML notations 47 Combined aggregation and generalization

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

UML notations 49 Use cases for a library

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

UML notations 51 Use cases

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 string 0+ course-exam 1 0+ tutor requires

UML notations 53 Activity diagram for course enrollment procedure

UML notations 54 State diagram: “update student data”