The pragmatic modeling

1
The pragmatic modeling
(V2 reviewed by Oscar Chappel from ILOG Company,
2008-02-25) (V1 in English Language)
Review by Pierre Bonnet Co-founder of the Praxeme
Institute pierre.bonnet_at_orchestranetworks.com 06
75 01 54 54
2
Preamble

• This presentation is not a UML course or object
  oriented course
• This is a training dedicated to the pragmatic
  modeling
• Prerequisite mastering UML design

3
Objectives of the sequence
Mastering procedures and guidelines ofthe
pragmatic modeling
4
Contents of the sequence

• Use cases modeling
• At the level of analysis
• At the level of design
• Processes modeling

5
Use casesAnalysis approach
6
Definition in the context of Praxeme

• A use case is an elementary interaction between
  one actor and the system
• Each use case treats a precise objective
  providing a real added-value for users

7
Process, use case and activity
Process
Actor 1, Tps1
Actor 2, Tps2
Actor 2, Tps3
Actor 5, Tps5
Step
Step
Step
Step
Actor 4, Tps3
Step
Activity
Activity
Activity
Activity

• Micro-process is also named use case
• If the execution leads to updating the database
  then this is a Business Action

Activity
Actor 1, Tps1
8
Definition

• The use case diagram

Use case
Obtaining a service
Overseeing sales
Actor
Participation
9
Definition

• Example

Functional domain
Accountancy management
Sending settlement orders
Use case
Actor
Participation
System boundary
10
Example

• A basic use case related to a functional domain

Managing external staffs
Supporting external staffs
Validating affectation of staffs
Manager of external staffs
11
Use-case approach

• Interactions between actors have been described
  in projects for a long time
• This is not new!
• However, in most of cases these descriptions are
  not well-defined
• The use-case approach is a better way for
  specifying these descriptions

12
Use-case approach

• Use cases may be used to describe needs of
  business users
• These are alternative documents that enhance the
  quality of usual functional approach
• In most of cases usual documents are
  heterogeneous there is a lack of standardization
  between projects
• Use cases allow for a formal description of needs

13
Use-case approach

• Setting up
• This is an orchestration of steps describing an
  interaction between one actor and the system
• This is a set of specific executions, may contain
  many different scenarios
• Each scenario is a simplified description all
  conditions and decisions are not described
• Unit of actor (one actor), unit of time (short
  life-cyle, no interruptions), unit of objective
  (a real added-value)
• For the user
• Analysis stage the use case relies on informal
  terms
• Design stage it relies on business vocabulary
  that comes from the semantic modeling

14
Use-case approach

• Elementary activities are sought by analyzing the
  text description
• For example
• Selecting an insurance claim
• Selecting a guarantee
• They may combine one or several user actions and
  one or several responses of the system
• Seldom several user actions
• Example displaying codes before keying data
• Sometimes several actions of the system
• In the same orchestration
• Preparing information keying data system
  treatment

15
Use-case approach

• First of all, utilization view appears as a
  collection of short texts
• Related to working situations
• Easily shareable
• This collection of texts must be well-structured
  so as to
• Facilitate exploitation of the utilization view
• Prepare for the future work

16
Use-case approach

• Use cases bring the external view of the system
• The use case diagram shows interactions between
  each user with the system
• This diagram gathers several use cases
• It is useful to express needs
• It makes the demonstration that user working
  situations are well taken into account
• It doesnt allow for structuring the system
  itself. Be cautious to not fall into the internal
  design

17
Actor

• Definition
• An actor is a role played by a user or another
  system vis-à-vis the system
• Type of actor
• Role
• Responsibility
• Example
• Customer
• Internal staff
• Manager of settlements

18
Actor

• In most of cases, an actor represents a human
  operator
• An actor may also be an external system
• A system that needs information coming from our
  system
• This is never a sub-system otherwise this would
  be an internal design

An actor is the one which obtains added-value by
using the use casewhatever it is a human or an
external system
19
Actor

• The model relies on a hierarchy of actors
• Via inheritance
• An actor of a sub-class is authorized to operate
  as the actor of its super class

20
Actor

• Two types of actors are identified
• primary actors for whom the system is running
• secondary actors that manage and oversee the
  system
• For example configuration manager, system
  manager, master data manager, business rules
  manager, etc.

21
Example (version of the analysis stage)
22
Improving the version of the analysis stage

• Removing redundancy is also required for the
  utilization view
• Each elementary activity appears only one time in
  the whole diagram of use cases
• The external design may rely on the semantic
  model
• The dialogue is less linear, procedural
• and more dynamic using a regular data flows on
  objects
• The only constraint to respect is life-cycles of
  business objects (state machines)
• The impact on GUI

23
Forms used to describeuse cases and scenarios

• Table of contents
• Use case definition
• Objective, context, events, actors
• Use case description
• Pre-condition, rules, list of scenarios
• Detailed description of the basis scenario
  (nominal)
• Detailed description of alternative scenarios

24
State machine of the use case

• The state machine drives the use case
• It describes the minimal logic that drives the
  interaction between the user and the system
• With help from the state machine, linear
  descriptions is avoided

25
State machine of the use caseExample

• A resumed state diagram for the use
  case insurance claim 

26
State machine of the use caseExample

• The detailed state machine that shows the
  orchestration of various activities regarding
   insurance claim  use case

Simplified notation
27
Use casesDesign approach
28
Limit of the analysis phase redundancy

• Crossing between use cases and activities
• Analysis phase shows some redundancies some
  activities are integrated more that one time in
  several use cases or inside a sole use case
• Example

Activity
Use case
Many times in the same use case
A same activity is located in several use cases
29
Limit of the analysis phase

• Redundancy in the pragmatic model could be taken
  over in the system, at the level logical models
• This redundancy prevents from using derivation
  rules so as to set up the logical architecture
• The checking procedure
• This is a procedure to obtain a better use-cases
  diagram
• Avoiding redundancy an activity must appear only
  one time in the whole use-cases diagram
• The target architecture is obtained when
  redundancy concepts are removed

30
Relations between use cases

• include
• Factorization of common activities
• extend
• Enriching a use case
• generalization specialization
• Setting up a hierarchy of use cases

• These terms will be use in the presentation
• Basis use case
• Subordinate use case

31
Include between use cases

• The relation include allows for factorizing
  elementary functions or actions
• Gains are
• Lightening the description of the basic use case
• Removing redundancy when a description may be
  used by several use cases
• Increasing reuse use cases are defined to meet
  this objective

Declaring a claim
Assigning a staff
Allocating to management
32
Include between use cases (example)

• Description of the scenario
• Display advertisements of the day
• The user enters the system
• Include the use case Identifying customer
• Validate the account
• Include the use case Validating account
• Display the balance

Withdrawing cash
Validating account
Identifying customer
33
Extend between use cases

• The extend relation allows for enriching a use
  case
• This relation allows for inserting into the basic
  use case complementary scenarios
• The basic use case doesnt know the subordinate
  use case and their execution conditions
• Extension point

Basic use case
Setting up a contract
Setting up arisk assessment
Subordinate use case
Setting up a quote
34
Extend between use cases

• The basic use case foresee extension points
• Inside its scenario
• This is a mean to describe where subordinate use
  cases will be able to insert themselves during
  execution
• The basic use case may contain several extension
  points
• A subordinate use case may be used several times
  in the same basis use case
• A subordinate use case may be executed for
  itself
• The subordinate case contains a condition
• The subordinate case is one that extends the
  basic use case
• The subordinate case will be executed at the
  expected position if its condition is checked
• Be cautious about the direction of the arrow
• The arrow goes from the subordinate use case
• The one that allows extension
• to the basic use case
• The one that contains extensions points and that
  may be enriched

35
Extend between use cases (example 1)

• Basis use case
• Two extension points
• blocking
• assembly line is stopped
• Subordinate use cases contain corresponding
  conditions
• If these conditions are validated then they
  participate in the execution

Basis use case
Putting down an element
Subordinate use case
Restarting a chain
Releasing an element
36
Extend between use cases (example 2)

• Case study SMABTP (French insurance company)
• Rules
• The use case Describing a claim declares an
  extension point a point where the internal state
  is well-known, steady and meaningful
• This point is known by the use case Connecting
  claims
• This one may decide to execute itself
• After, the execution of the use case Describing
  a claim is resumed

Connecting claims
Describing a claim
37
Generalization and use cases

• Generalization relations show a hierarchy between
  use cases
• Subtypes mechanisms
• This is the usual principle of inheritance, as
  well-known in the object oriented approach
• Rules
• All capabilities of Declaring a claim are
  alsoavailable for Describing a claim
• All actors authorized for the first use caseare
  also authorized for the second

38
Generalization and use cases

• A trap to avoid

Avoid redesigning specializations that already
exist in the class diagram
Subscribing a contract
Subscribing a life contract
Subscribing a health contract
39
Generalization and use cases

• Reminder
• Generalization relations are also available for
  the description of actors
• Example

40
Gains of the design view

• Use cases at the level of the design stage
• Improving use cases that are obtained at the end
  of the analysis stage

The use-case oriented approach allows for
improvingthe quality of the functional
specification
41
Gains of the design view

• The proof of improvement
• Below (next slides)
• New version of the crossing between activities
  and use cases so as to check lack of redundancy
• New version of the use-cases diagram

42
Gains of the design view

• Crossing between use cases and activities
• With help from the design phase redundancy is
  removed

43
Gains of the design view

• Example
• Case study SMABTP

44
Gains of the design view

• Three types of relation between use cases
• Include
• Extend
• Generalization (inheritance)
• These relations allow for a better organization
  of use cases (optimization, removing redundancy)
• Basis use case
• Subordinate use case
• Possibility to describe several scenarios of each
  use case

45
Gains of the pragmatic modeling

• Description of the real activity of users
• Actions
• Relying on easily shareable and understandable
  formalisms
• A good opportunity to analyze organizational
  issues
• Removing redundancy
• A better organization of functions that allows
  for streamlining end-user tools
• A good approach to encourage a better ergonomics
  
• Reuse
• Subordinate use cases are reusable in several
  contexts

46
The process modeling
47
The design of the organization

• Relying on a global vision of the organization
• Processes
• Span beyond system boundaries
• Involve several types of resources
• Provide real added-values for the organization
• Organization
• The choice of a management style
• Levels of responsibilities
• Interactions mechanisms
• Orientation customer rather than internal view,
  etc.
• Types of controls
• Responsibilities affectations
• Roles
• Permission management
• Etc.

48
Functional approach to design processes

• The usual approach is oriented towards functions
• Therefore
• Actions rather than objects
• Top down hierarchical decomposition
• A process is divided into activities that are
  divided into sub-activities, etc.
• Arbitrary limitations of this decomposition are
  stated
• Levels of decomposition
• Terminology

49
Limits of functional approach

• Lack of business innovations
• This approach
• Generates redundancy because of hierarchical
  decomposition
• Doesnt encourage large innovation because
  processes are designed from functional existing
  situations
• Relevant at the level of analysis stage but not
  for the design time
• Reproduces existing organizations, existing
  processes

50
Process approach relying on objects

• Identifying the main object of the process
• Thinking objects rather that functions
• This is a main class of the semantic model
  (Business Object) or the pragmatic model
  (Administrative Object)
• Getting the lifecycle of this object
• This is its state machine
• Deducing activities
• Assigning activities
• Actors come into play at this level

51
Process approach relying on objects
Lifecycle of Business Object (semantic aspect)
First version of the process conceptual process!
Organization processes
Automatic!
Benchmarking!
52
UML notation for processes
Swim-lanes
Actor (Type of actor, role)
Catching event
Activity
Object (instance of a business class)
Throwing event
Conditional branch
53

• Thanks - end