Extending goal modeling: the Map
approach
1- Motivation
2- Key concepts
3- Constructing Maps
4- Operationalizing Maps
Motivation
Requirements relate to

Goals

Different ways of achieving goals
Eliciting strategies by which goals can be achieved is as
important as eliciting goals themselves
Need a balanced modelling of goals and associated
strategies

An ordering between goal achievement
Modelling the ordering relationships between goals is
necessary to elicit a set of goals which ensures the
completeness of the requirements specification
Motivation
Goals
Different ways of achieving goals
An ordering between goal achievement
This provides a process modelling perspective
Introduction to Maps
sij2
Ii
Manager
si
sk
Ij
sji
sjk
ski
Start
Wishes to
express the
business in terms
of intentions and
strategies
sij1
Process
leader
Stop
Ik
ss
Expresses the
rationale of
business processes
Project
Manager
Describes IS services in terms
of intentions and strategies
to achieve them
Extending goal modeling: the Map
approach
1- Motivation
2- Key concepts
3- Constructing Maps
4- Operationalizing Maps
The notion of a Map
An ordering of sections <Ii, Ij,
Sij> of
such
that theand
achievement
A Map is a non deterministic assembly
intentions
strategies
of Ii is the pre-condition for
achieving Ij with the strategy
Sij
sij2
Intention
Ii
si
sij1
sji
sjk
ski
Start
sk
The goal to be achieved
Ij
Stop
Ik
ss
Strategy
The way to
achieve an intention
A section is a triplet < Intention Ii, Intention Ij, Strategy Sij> : an
abstraction of both a process & a service
Key concepts





Intention
Strategy
Section
Section refinement
Summary
Ii
Ij
Stop
Start
Ik
Example of a Map
In a semi-automatic
manner
Grant
a loan
Start
By an
assistant
By flexible
instalments
with fixed
due date
By
contract
renegotiation
By fixed
schedule of
fixed
instalments
By fixed
schedule
with
revisable
instalments
By debt
recovery
Manage
a loan
Stop
At normal end
Intention
An intention is a goal to be achieved, an objective to be realized.
An intention expresses what is desired but not how to obtain it.
Grant a loan
Manage a loan
Start
Make a loan offer
Collect loan request data
Confirm the offer
Sign a contract
Stop
Grant
a loan
Manage
a loan
Intention
Any map has two particular intentions Start and Stop
 Start begins the process
 Stop Stops the process
Stop
Start
Intention
• Standardize intention wording
Intention : Verb <Target> [<parameter>]*
Target : Object of the verb
ex: Grant Verb (a loan)Target
• Goal template helps to complete intention wording
Grant Verb (a loan)Target (to our bank customer)ben
(based on customer request)so
Strategy
A Strategy is:
 a manner of achieving an intention
 a means of reaching an objective
Flexible instalments
with fixed due date
Manage
a loan
Ex: Flexible instalments with fixed
due date (manner)
Instalments can be of different amounts and paid at customer
convenience. However, on fixed dates, the bank checks if the
total amount paid is within the acceptable window or not.
Strategy
A Strategy is :
• a manner of achieving a goal
• a means of reaching an intention
By an assistant
Grant a loan
Ex: By an assistant (means)
Grant a loan can be done by a software assistant
Strategy
Examples :
 Generate alternative loan offers on the spot (manner)
 Collect loan request data by inter-computer transfer
(means)
 Cancel a loan offer on expiry of offer period (manner)
 Activate the contract on customer confirmation
(manner)
Strategy
The strategy is associated to the intention to which it applies:
 Grant Verb (a loan)Object (in a semi-automatic manner)Manner
 StopVerb (a loan)Object (at normal end)Manner
 GrantVerb (a loan)Object (by an assistant)Means
The manner and the means are parameters
of the intention verb
Intention versus strategy
 Intentions are stable elements: generic for a domain
Ex: Grant a loan
Manage a loan
 Strategies change across organizations within a domain
Ex: fixed schedule with fixed instalments
flexible instalments with fixed due date
Strategies are discriminating elements.
 Strategies suggest alternative ways of achieving an
intention
Ex: in a semi-automatic manner
by an assistant
.
Exercise (1)
A system is to be specified for booking/cancelling airline seats
1- Identify intentions
2- Identify strategies
Section
In a
semi-automatic
manner
Grant
a loan
A section is the basic unit of the Map
Start
A section S is a triplet
<IntSource, IntTarget, Strategy>
Ex: S1=<Start,Grant a loan, in a
semi-automatic manner>
Section
S
Int target
Section semantics
S1=<Int source, Int target, S>
Int source
• IntSource must be satisfied for IntTarget to be
achieved using strategy S.
• The situation resulting from the achievement of
IntSource is a pre-condition of the section
• The situation resulting from the achievement of
IntTarget is the post-condition of the section
• S models the transition from an initial to a final
situation
• The final situation results from the application
of business rules associated to S.
Section
S1=<Start, Grant a loan,
in a semi-automatic manner>
In a semi-automatic
manner
Grant
a loan
Start
• The pre-condition of the achievement of Grant a
loan is: the customer loan request is posted
• The post-condition is : the loan Granted or
customer loan request rejected
• The transition evaluates the request in a semiautomatic manner following the bank’s
business rules
Section
S
Int target
Int source
A variant of the section semantics:
product centered
S1=<Int source, Int target, S>
• The section models a transition from a source
situation to a target situation
• The source situation is described as the
product state after the achievement of IntSource
• The target situation refers to the product state
after the achievement of IntTarget.
• The section is characterized by an interface
which is written <(source situation), Int target S>
• The section has a body which is an abstraction
of the process to reach the target situation.
Section
Interface
S1 : <(customer loan request posted),
Grant a loan in a semi-automatic manner>
Intention : Grant a loan in a
semi-automatic manner
Source situation:
Customer loan
Request posted
Section S1
Process
abstraction
Product parts
Target situation:
Loan Granted
Target
Section
This way of describing a section makes it possible
to connect the product and the process
Source
Situation
It’s important!!!
Target
Situation
Request
Customer
Cust_N
Cust_Name
Cust_Adr
Req_N
Amount
Duration
Desired_Rate
Source Situation
Loan
Loan_N
Amount
Duration
Rate
Beg_Date
Section
In a semi-automatic
manner
Grant
a loan
Start
General
Code: S1
Comment: the section represents the process
of the bank analysing a customer loan request and deciding
to make or not an offer to the customer
(who accepts it or refuses it)
Interface
<(Customer loan request posted);
Grant (a loan)Object
(in a semi-automatic manner)manner>
describe a section
Body
Pre-condition: Customer loan request posted.
Post-condition: loan Granted or request rejected or
offer refused
Description: The strategy implies a partial and automatic
filtering of the request but a human decision about loan
granting
Exercise (2)
Describe the section <Start, Reserve seat, Directly>
Sections in a Map
A section is a cohesive component coupled
to other components in the map
In a semi-automatic
manner
C1
Start
Grant
a loan
C3
By fixed
C2 By an
schedule of
C4 fixed
assistant
C7
C5
instalments By debt
By flexible instalments
with fixed By fixed
Stop
recovery
due date schedule
with
revisable
Manage
At normal end
By
instalments
a loan
contract
C8
renegotiation C6
The Map includes 8
components
Sections in a Map
Several strategies between 2
intentions form a
multi-thread
The multi-thread :
 introduces various ways of
achieving the same intention
 an OR relationship between
sections (the two strategies can
be applied or only one)
In a
semi-automatic
manner
Start
C1
C2
By an
assistant
Grant
a loan
Sections in a Map
Grant
a loan
Manage a loan
Several exclusive strategies
between 2 intentions constitute
a cluster
A cluster introduces an XOR
relationship between sections
Grant
a loan
C4’
Manage
a loan
Instalment strategy
Sections in a Map
Any sequence of several sections
forms a path
In a
semi-automatic
manner
Start
C1
Grant
a loan
C4
By debt
recovery
By flexible instalments
with fixed due date
C8
Manage
a loan
A path introduces
 an ordering between sections
 an execution constraint
Stop
Sections in a Map
Several combinations of
strategies from Start to Stop
form a multi-path
In a semi-automatic
manner
to Grant
a loan
Start
Grant
a loan
Start
By an
assistant
By
renegociation
of the contract
By flexible
coverings with
By notification Fixed due date
of the end of the offer
By
Predefined due date
at revisable rate
contentious
Manage
a loan
Stopr
By notification
of the end of the
offer
By
contentious
Manage
a loan
Stop
By a normal end
of the loan
A map models variants in
a process
By a normal
End of the loan
Exercise (3)
What are the relationships between strategies in the sections
between the pair of intentions Start and Reserve seat
Propose a revised graph if necessary
Section refinement
A section can
be deployed as
a Map
In semi-automatic
manner
Start
Grant
a loan
Start
By partial
filtering
By human
evaluation
Without
filtering
Post
a loan request
On bank
acceptance
Make a loan
offer
On customer
acceptance
By bank refusal
On offer
expiry
Stop
By customer
request withdrawal
Section refinement
S
Int target
Int source
Section refinement
is a recursive mechanism
The refinement:
 Introduces a relation ‘Refined by'
between a section and a Map
 It can be applied as many times
as necessary
Map as a whole
Map C
Every map can be
abstracted as a section
General
Code : C
Description : Managing bank loans granted in
response to customer requests
Interface
<(customer loan request posted);
ManageVerb (a bank loan)Resultt>
Body
Pre-condition: customer loan request posted
Post-condition: loan repaid
Comment : the map contains various strategies
for request analysis & evalaution and loan
management
Exercise (4)
Refine the section <Start, Reserve seat, Directly>
Map refinement
CC
a
b
R
E
F
I
N
E
M
E
N
T
ab1
ab1
c …
A 1st level
B
S
T
R
A
C
T
I
O
N
bc
ab2
Maps Hierarchy
2nd level
CCab1
a
b
C
bc
ab2
a
ab2
ab1
c …
b
ab1
c …
bc
ab2
3rd level
C
a
b
c …
ab1
bc
ab2
CCab2
a
b
c …
bc
ab2
ab2
ab1
Map refinement: naming conventions
Coding conventions for maps
a
 code each Map intention
In a semi-automatic
Start
manner
with a letter starting from a
ex : a, b, c, d
1
b
2
By an
assistant
1
c
Manage
a loan
Grant
a loan
By
flexible
instalments
with fixed due
date
1
2
At normal
end
By debt
recovery
d
Stop
 For each pair of intentions,
number the strategies
starting from 1
– ex : 1 & 2 (ab)
– 1 (bc)
– 1 & 2 (cd)
Map refinement: naming conventions
Coding conventions for maps
local codes in a Map
C
– Intentions : a, b, c, d
a
cd2
b
– Sections : ab1, ab2, bc1, cd1,
cd2
c
d ab1
ab2 bc1
cd1
The Map constitutes the
naming context
absolute codes
- Intentions : C.a, C.b, C.c, C.d
– Sections : C.ab1, C.ab2, C.bc1,
C.cd1, C.cd2
Map refinement: naming conventions
C
a
b
c
d
cd2
cd1
bc1
ab2
ab1
a
1
2
b
Refined by
1
c
Absolute references :
Map : C. Cbc1
Intentions : C.Cbc1.a
Sections : C. Cbc1.ab1
Cbc1
a
b
c
bc1
ab1 ab2
Map refinement: naming conventions
CC
a
b
R
E
F
I
N
E
M
E
N
T
ab1
ab1
c …
A 1st level
B
S
T
R
A
C
T
I
O
N
bc
ab2
Map hierarchy
2nd level
CCab1
a
b
C
bc
ab2
a
ab2
ab1
c …
b
ab1
c …
bc
ab2
3rd level
C
a
b
c …
C.Cab1.Cab2.ab2 ?
ab1
bc
ab2
CCab2
a
b
c …
bc
ab2
ab2
ab1
Exercise (5)
1
By flexible
instalments with fixed
due dates
Manage
a loan
Grant
a loan
1- Define local codes for the refined map
of section bc1 in C
2- Define the corresponding absolute
codes and place them in the C hierarchy
c
b
By deviations
detection
Check
Repayments
at fixed
due date
Start
By posting
the customer
repayments
On loan end
Stop
Summary
 Business processes are expressed intentionally,
thus avoiding the bother of the details of process
implementation
 Strategies are made explicit, thus showing the
different alternative ways of obtaining a result
 Sections provide a modular organisation of a
process
 The Map includes a multiple assembly of sections
(through multi- path) with possibly multiple
alternative ways of achieving intentions (through
multi-threads) to reach the same result
 Map recursion allows modelling at different levels
of abstraction
Exercise (6)
Propose a map representing the As-Is process
of the ELEKTRA company
Exercise (6)
The ELEKTRA company produces and supplies electricity to citizens of Dream, a country of the
south of Europe. The company has a monopolistic position for many years and even centuries but
ELEKTRA is conscious of the need for change, given the EU imposed deregulation of the sector.
The way in which customers are currently serviced is as follows: to get a connection in their
house, customers must visit the companies offices. This leads to long customer queues. It is also
found that providing a connection itself takes too long. Once a connection is provided, the
customer consumption of electricity is measured by meter readers who visit homes. Every home
is visited every two months. Meter readers work according to a pre-defined plan of meter reading
which is automatically produced by the ELEKTRA information system. Some meter readers note
down consumptions manually on paper but most of them use a device which allows them to
transmit the consumption to the IS in an automatic way. The latter was found to be error less than
the former in generating bills. It is found nevertheless that there are too many errors in the bill
and bills are inordinately delayed. In order to collect the payment of bills, the company offers to
its customers a number of different ways. Dream citizens like the conventional cash payment
mode. This has the advantage to allow them getting a payment receipt. They can pay cash at Post
offices, in ELEKTRA offices and in a number of Private offices like pharmacies or groceries
which are entitled to receive ELEKTRA payments. Payments made to Post offices and are too
expensive and not efficient. Finally, electricity supply can be stopped either on customer request
or by company’s decision (when the bill has not been paid 30 days after the deadline).
Extending goal modeling: the Map
approach
1- The notion of a Map
2- Key concepts
3- Constructing Maps
4- Operationalizing Maps
Constructing Maps
The construction process as a set of tasks
1. Formulate the Map interface
2. Identify intentions
3. Identify strategies
4. Introduce precedence links between intentions
5. Improve Map quality
6. Describe the Map and its sections
7. Define the associated product
Formulate Map interface(1)
a)
b)
Identify the situation
Identify the intention
Source document
The objective is to
Manage our customer loans
in response to their requests
<(Customer loan request posted), Manage a loan>
Identify intentions (2)
a) Identify P, the main parts of the product
b) Select I verb, the intention verbs abstracting from the description provided in
documents or use domain related knowledge
c) Build P*I verb by combining verbs and product parts
c) Select I, the set of relevant intentions
P
Request
I
verb
Capture, Post
Evaluate, Analyse
Offer
Make
Loan
Grant, Give
Manage, Stop
I
Capture a request, Evaluate a
request
Make a loan offer
Grant a loan
Manage a loan
Stop a loan
Identify strategies (3)
Intention
Capture a
request
Evaluate a
request
Make a loan offer
Grant a loan
Manage the loan
Stop the loan
Manner (from the source document of the bank)
Strategy
Most of the time, the bank filters the requests in order to
eliminate unacceptable ones (e.g. customers currently
having loans…).
Sometimes, requests are posted without being filtered
With filtering
The bank wants to generalize its recently developed expert
system that evaluates requests automatically.
Otherwise, the evaluation is done by an expert.
Automatically
Without filtering
Manually
The expert system decides and makes an offer
In the other cases the final decision is made by a bank expert
The loan is granted if the customer accepts the offer
Automatically
On bank expert
proposal
On customer
acceptance
Loan management provides a certain flexibility to the
customer who can pay instalments of a variable amount at
dates which are suitable to her. However the bank checks the
total amount repaid at fixed due dates and take corrective
action if deviations exceed the tolerance value.
By flexible
instalments with
fixed due dates
The loan can end normally when the total amount and interest
have been reimbursed.
In case of problems the loan is closed and the procedure for
recovering the debt will be carried out by the debt recovery
department
Normally
By debt
recovery
Identify strategies (3)
Start
With filtering
Capture
a request
Manage a loan
Without filtering
With customer
agreement
Manually
Automatically
Grant a loan
On bank expert proposal
By flexible
instalments with
fixed due date
Evaluate
a request
Normally
Make a loan offer
Automatically
By debt
recovery
Stop a loan
Introduce precedence links between
intentions(4)
Start
Without filtering
With filtering
Capture
a request
Automatically
Manually
Evaluate
a request
Automatically
Stop the loan
By debt recovery
Make
a loan offer
With customer
agreement
Normally
Stop
On bank expert
proposal
Manage a loan
By flexible
instalments
with fixed due dates Grant a loan
Introduce precedence links between
intentions(4)
Start
Fixing
Start and Stop
Without filtering
With filtering
Capture
a request
Automatically
Manually
Evaluate
a request
Automatically
By debt
recovery
Stop
On bank expert
proposal
Make
a loan offer
With customer
agreement
Normally
Manage a loan
By flexible
instalments
with fixed due dates Grant a loan
Improve quality (5)
Quality requirements
 Intentions must be of the same abstraction level
• No intention must be a subset of another
• No intention must be a means to reach another
• An intention must be abstract, not be a simple operation for
creating or manipulating a product part.
 Any Map must be “quasi-live”
• It must include a Start intention and a Stop intention
• Any path of the Map must lead from Start to Stop
Improve quality (5)
Transformation rules
Rule #1 :
•
•
Situation : an intention I is a means to achieve another intention J
Action : transform intention I into a strategy for achieving J
Rule #2 :
•
•
Situation : two (or more) intentions lead to the same product part
Action : introduce an intention which abstracts them and use refinement mechanism to
keep track of details if useful
Rule #3 :
•
•
Situation : several supplementary intentions
Action : introduce an intention which abstracts them and use refinement mechanism to
keep track of details if useful
Rule #4 :
•
•
Situation : several strategies between a pair of intentions are exclusive
Action : cluster the strategies
Rule #5 :
•
•
Situation : several sections are part of the same transaction (all are executed or not)
Action : introduce a section which represents this transaction and use refinement
mechanism to keep track of details if useful
Improve quality (5)
Rule #6 :
•
•
Situation : a Map does not include a Start intention or Stop intention
Action : add the missing intention (s)
Rule #7 :
•
•
Situation : a Map
Action : ensure that every section is quasi-live
Rule #8:
•
•
Situation : a section
Action : introduce new strategies if they make sense
Improve quality (5)
Start
Without filtering
With filtering
Capture
a request
Rule #2 :
Automatically
Manually
•Situation : two (or more) intentions lead
to the same product part
Evaluate
a request
•Action : introduce an intention which
abstracts them and use refinement
mechanism to
keep track of details if useful
“Capture a request” and “Evaluate a request”
can be abstracted as “Post a loan request"
Post
a loan request
Improve quality (5)
Start
Without filtering
With filtering
Capture
a request
Manually
Automatically
Evaluate
a request
Start
Applying Rule #2
Automatically
Without filtered capture
With filtered capture
Post
a loan request
By human
evaluation
Improve quality (5)
Start
Automatically
Without filtered
With filtered capture
capture
Post
a loan request
By human
evaluation
On bank expert
proposal
Automatically
Rule #5 :
•Situation : several sections are part of
the same transaction (all are executed
or not)
•Action : introduce a section which
represents this transaction
Make
a loan offer
Improve quality (5)
Start
Without filtered
With filtered capture
capture
Rule #5 :
•Situation : several sections are part of a
same transaction (all are executed or By human
evaluation
not)
•Action : introduce a section which
represents this transaction
The path “Post a request automatically” 
“Make a loan offer automatically” is a direct path from
“Start” to “Make a loan offer”
Post
a loan request
Automatically
On bank expert
proposal
Make
a loan offer
Improve quality (5)
Start
With filtered
capture
Post
a loan request
Rule #5 :
•Situation : several sections are part of a
same transaction (all are executed or
not)
Without filtered
capture
By human
evaluation
•Action : introduce a section which
represents this transaction and use
refinement mechanism to keep track of
details if useful
“Post a request” and “Make a loan Offer”
are parts of the same transaction to “ Grant a loan”
Automatically
On bank expert
proposal
Make
a loan offer
Improve quality (5)
“Post a loan request” and “Make a loan offer” belong
to a refined view of “Grant a loan”
Start
By an assistant
In a semi-automatic manner
Start
Without filtered capture
With filtered capture
Post
a loan request
By human
evaluation
On bank expert proposal
Make
a loan offer
Grant a loan
Improve quality (5)
Rule #6 :
•Situation : a Map does not include a Start intention or Stop intention
•Action : add the missing intention (s)
Start
With
filtered capture
By human
evaluation
Without
filtered capture
Post
a loan request
On bank expert
proposal
Make
a loan offer
Stop
Improve quality (5)
Rule #7 :
•Situation : a Map
•Action : ensure that every section is quasi-live
Start
With
filtered capture
By human
evaluation
Without
filtered capture
Post
a loan request
On bank expert
proposal
Make
a loan offer
On customrer
agreement
Stop
Improve quality (5)
Rule #8:
. Situation : a section
. Action : introduce new strategies if they make sense
Start
With
filtered capture
By human
evaluation
Without
filtered capture
On bank expert
proposal
Post
a loan request
By customer request
withdrawal
Make
a loan offer
By offer expiry
With customer
agreement
By bank refusal
Stop
Improve quality (5)
Final Top-level Map
Start
By an assistant
In a semi-automatic manner
Stop
By debt recovery
Grant a loan
By flexible instalments
with fixed due date
Normally
Manage the loan
Document the Map (6)
General
Code : Pr
Description : Manage the bank loan
Map Pr
6. Document the
Map
in response of a customer request
Interface
<(a loan request);
ManageVerb (a bank loan)Result>
Body
Pre-condition: a customer makes a loan request
Post-condition: The request and the corresponding
loan (if it is Granted) are enclosed
Comment : There are two agreement strategies
(expert system and semi-automated) but only one loan
Management strategy (By adjustable coverings
in fixed due dates)
Document the Map (6)
In semiAutomated manner
Grant a loan
Start
a
1
b
6. Document the
section
General
Code: ab1
Description: the section represents the process
of recording and analysis of the loan request emitted
by a customer, the decision taken by the person in
charge for the bank to make an offer to the customer
(who agrees or refuses it) or to refuse the request.
Interface
<(The applicant makes a loan request);
Grant(a loan)Object
(in a semi-automatic way)manner>
Body
Pre-condition: a customer makes a loan request
Post-condition: The request has a status(A/R), i.e.
the loan is Granted and accepted
Comment: the strategy implies an automated partial
screening but needs a human decision.
Define the product (7)
7. Define the product
Customer
Cust_N
Cust_Nam
Cust_Adr
Status
Profile
Makes
Loan
Request
Requ_N
Amount
Duration
Hop_Rate
Status
becomes
Loan_N
Rate
Due_date
Aggregate of
Version
Amount
Duration
Monthly_payt
Date
Pay off
Date
Amount
Penalty
Date
Amount
Status
Exercise (7)
Improve the “Renault” map using quality rules
Follow the suggested steps if you want so
1.
2.
3.
5.
6.
Check intention wording
Check the OR/XOR relationships (Is rule #4 applicable?)
Is it an intention which is a means to achieve another one?
(is rule# 1 applicable)?
Check if two consecutive intentions are not dealing with the
same product part (just changing the state): is rule#2 applicable?
Use the refinement mechanism .
Any suggestion for new strategy? (apply rule#8)
7.
8.
Now you get a transformed map
Abstract it as a section defined by its interface
4.
RENAULT Map
On Renault vendor desktop
Start
By Spanish
vendor
desktop
by an agent
With SOFT*
Collect the data
of the contract
Automatically
Automatically
Evaluate
the risk
By offer
expiry
Decide on
the offer
Manually
By adding
contract data
Directly
By Renault
refusal
By customer
refusal
Contract
By customer
agreement
Stop
Exercise (8)
1- Brainstorm to identify the key intentions in the process of building
Maps and some strategies to achieve them.
2- Organise intentions and strategies to propose a top level map that
can guide the construction of maps
Recommendation : use the proposed set of activities but introduce
more flexibility in the process by introducing various strategies
Extending goal modeling: the Map
approach
1- Motivation
2- Key concepts
3- Constructing Maps
4- Operationalizing Maps
Operationalizing Maps
Bridging the gap between intentions & strategies and system
conceptual specification
O
P
E
R
A
T
I
O
N
A
L
I
Z
A
T
I
O
N
Goals and strategies
Intentional level
Operational level
Conceptual schema
A
B
S
T
R
A
C
T
I
O
N
Operationalizing Maps
Intentional levels
1
Strategic ‘map’:
high level intentions & strategies
2
n
Tactical ‘maps’:
operationalisable intentions &strategies
Conceptual Schema
Operational level
Expressing
requirements
embedded in maps
in conceptual terms
Operationalizing Maps
 Manage customer loans
Capture
request data
 Grant a loan in a
semi-automatic manner
Without filtering
With filtering
Intentional level
Operational level
Customer message
HTML form
Request filtering rule
Customer
Customer checking rule
Request
Operationalizing Maps
C
Approach:
Operationalizing each section in
conceptual terms
Intentional level
Operational level
Dynamic
fragment
Interface
fragment
Static
fragment
Relating each section to a
schema fragment composed of :
{dynamic fragment,
static fragment,
interface fragment}
Operationalizing Maps
Operational level
Application conceptual schema =  Schema fragments
Static fragment
Interface fragment Dynamic fragment
M1
M1
Customer
Customer
Request
...
concerns
If new customer
Register
Cust_N
Record
...
Name First name . . .
Request
Request
Customer
Conceptual model
The trilogy : Object ,Operation, Event
Object
Operation
Ex :
• Give a status to the posted request
• Create a contract
• Collect data of the request
Ex :
Offer, Request, Contract,
Instalment
Event
Ex :
• Arrival of customer loan request
• The offer expiry date is just reached
• The customer accepts the offer
Conceptual model
Causality Paradigm
Ex 1 : a timer
OBJECT
MODIFY
Operations change states of objects
Events acknowledge noteworthy
state changes of objects
OPERATION
ACKNOWLEDGE
Ex 1 : set a timer
TRIGGER
Events trigger operations
EVENT
Ex 1 : when an offer is made
Conceptual model
Causality Paradigm
Ex 2 : the status of the offer
is updated to cancelled
OBJECT
MODIFY
Operations change states of objects
Events acknowledge noteworthy
state changes of objects
OPERATION
ACKNOWLEDGE
Ex 2 : cancel the offer
TRIGGER
Events trigger operations
EVENT
Ex2 : the timer has just passed to zero
Conceptual model
Object
proposed offer
accepted offer
After
Before
An offer has
just been accepted
Accept the offer
Operation
Event
Conceptual model
An offer has
just been accepted
Create the contract
Null Contract
Effective Contract
Conceptual model
Typology of events
1. Internal event : acknowledges a state change of a system object
– An offer has just been accepted
– Stock rupture
– An account has just become debtor
2. Temporal event : acknowledges a time change
– Today at 1800 hrs
– Every Monday
3. External event : acknowledges the arrival of an external stimulus
– The decision of the expert has just arrived
– A cheque of a loan instalment arrives at the bank
– A loan request has just been made by a customer
Conceptual model
Interaction between the system and its environment
System Environment
System
responses
Stimulus
System seen as a
state machine
Conceptual model
Object
Objects can be modelled in terms
of the E/R model, UML, etc.
Entity Type
Relationship Type
1,1
Offer
Offer_Num
To
Attributes
0,n
Customer
Cust_Num
Constraints (Key, Cardinality)
Conceptual model
Operation
An operation represents an action
leading to object state change
Create contract
Contract
The Conceptual Model
Event
An event
• acknowledges a noteworthy state change
of an object
• triggers one or several operations,
perhaps conditionally
C : the payer is different
from the customer
Request
Arrival of a request
Event
Create offer
C
Set timer
Register Payer
Payer
Timer
Offer
Operationalizing Maps
Interface
Request
• Map Driven approach
Static fragment
name
Customer
Dynamic fragment
Without
filtering
Start
Request
Post a loan
request
Event
Arrival of a request
Create offer
C
Each section in the Map
is operationalized as :
• Dynamic fragment
• Static fragment
• Interface fragment
Set timer
Register Payer
Payer
Timer
Offer
A dynamic fragment
Without
filtering
Start
Post a loan
request
C : the payer is different
From the customer
Request
Arrival of a request
Event
Create offer
C
Set timer
Register Payer
Payer
Timer
Offer
An interface fragment
Request
Customer
Id
Payer
Offer
Amount
Period
...
Due date
Name
...
A static fragment
Person
Pid
Pname
……
Payer
Customer
Cstatus
Makes
Has
Request
Rid
Rdate
…..
Leads to
Offer
Oid
Oamt
Orate
Timer
Uses
No_of_
days
Exercise (9)
By adjustable
instalments with fixed
due dates
1- Model the fragments associated to the section
<(loan is in its course), Manage due date
by posting customer repayments>
Manage
a loan
Grant
a loan
Refined map
By deviations
detection
Manage
due date
Start
On loan
end
By posting
customer repayments
Stop
Exercise (9)
Rules :
1- every due date the bank checks if the total amount reimbursed by the
customer fits in a certain amount window. The window is calculated as
follows : total amount for fixed reimbursements,
RegularTot +/- 3* MfixAmount (monthly fixed amount )
2- if the actual reimbursed total is less than RegularTot – 3*MfixAmount,
the customer gets a penalty (fixed amount)
3- When a cheque for repayments arrives the penalty (if any) is reimbursed
first but only if the repayment is > penalty amount. The rest of the cheque
amount (if any) is calculated and memorised as loan Pay-off
The Operationalizing Process
Interface
Static
Dynamic
Section
Static
Model
Fragments
Dynamic
(1)
Interface
Fragment
Descriptor
Document
Global
index
Documentation
Correspondence between a Map section and a conceptual fragment
C.Cab1 .ab2
a
section ab2 of map C.Cab1
b
2
c
1
Fragment Fab2
Fab2.Dyn
Relative reference :
Fab2
Absolute reference :
C.Cab1.Fab2
Dynamic
schema (event
and operation)
Fab2.Int
Interface
schema
(message)
Fab2.Stat
Static schema
(data)
Documentation
Dynamic Fragment
General
Code : <Identification code >
Event : <code Evt (Evi)> : <Event name>
Type : external / temporal / internal
Instance : <code of input message if event type is external>
<predicate>
Body
Graphical Representation : <tri-alternate graph >
Transition description :
When < event happening >{[ If <condition > (<condition’s code
>)][For each <factor > (< factor code >)] Do {< operation > (<
operation code>)}}
The Operational Documentation
Dynamic Fragment
Detail
Operations :
{<operation code (Opi)> : <name>
Type : creation / update / deletion / message sending <object name>
Rules : {<calculation rule>, < transfer rule>} }
Conditions :
{<code of condition (Ci)> : < simple condition >, < complex condition >}
Factors :
{<code of factor (Fi)> : <description of the procedure of calculation of the
objects being used as entry parameters of the iterative execution of the
operation >}
Documentation
Static fragment
General
Code : <Identification code >
Body
Graphical Representation : <entity / relationship schema >
Detail
Entity-type :
{Code : <Eti>
Name : <name of entity-type>
Definition : <short definition >
Key : {<name of attribute>}
List of attributes : {<name, [definition], domain, constraint>} }
Documentation
Interface fragment
General
Code: <identification code >
Body
Graphical Representation : {<object schema >}
Detail
Messages :
{Code : < absolute reference (Mi)>
Type : input message / output message
Textual Specification :
'{' {<fields> : <simple type > / < list type > / < structure type >} '}'
[existence predicate : < Boolean expression >] }
Readings
1- “Fitting Business Models to System Functionality
Exploring the Fitness Relationship”
C. Salinesi, C. Rolland, A. Etien
Proceedings of the International Conference on Information
Systems Engineering,
CAISE’03, Springer Verlag (pub) 2003
2. “A multi-model view of process modelling”
Colette Rolland, Naveen Prakash, Adolphe Benjamen
Requirements Engineering Journal, 4(4) pp 169-187, 1999
Exercise (10)
Model the Map representation system as a class diagram
expressed with UML notations
Exercise (11)
1- Propose a map Msap representing the top-level view of the
functionality offered by the Material Management module of SAP
(see SAP book chapter)
2- Use the section description to relate Msap sections to the
software functionalities
3- Propose refined maps of some sections if possible