1 / 54

UML Notations in CommonKADS

UML Notations in CommonKADS. Activity diagrams State diagrams Class diagrams Use-case diagrams. Background UML. Nineties: number of popular object-oriented methods Unified Modeling Language: proposal for set of standard notations wide attention see www.rational.com

portis
Download Presentation

UML Notations in CommonKADS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related