Many laws, e.g., those concerning taxes and social benefits, need to be operationalized and implemented into public administration procedures and eGovernment applications. Where such operationalization is warranted, the legal frameworks that interpret the underlying laws are typically prescriptive, providing procedural rules for ensuring legal compliance. We propose a UML-based approach for modeling procedural legal rules. With help from legal experts, we investigate actual legal texts, identifying both the information needs and sources of complexity in the formalization of procedural legal rules. Building on this study, we develop a UML profile that enables more precise modeling of such legal rules. To be able to use logic-based tools for compliance analysis, we automatically transform models of procedural legal rules into the Object Constraint Language (OCL). We report on an application of our approach to Luxembourg’s Income Tax Law providing initial evidence for the feasibility and usefulness of our approach.

1. Using UML for Modeling Procedural
Legal Rules
Approach and a Study of Luxembourg’s Tax Law!
Ghanem Soltana Elizabeta Fourneret Morayo Adedjouma !
Mehrdad Sabetzadeh Lionel Briand
SsoftwareV verificVation & va.lidlaution
University of Luxembourg, Luxembourg!

2. How did this work come about?
• Collaboration with
Government of
Luxembourg
• CTIE: Government’s IT Centre
• ACD: Tax Administration Department
• New tax system under development
• System needs to be compliant with the law
2

3. Yes
No
Context and motivation
3
Test cases
Actual
software
system
✗
Traces to
Traces to
Input to
Input to
Analyzable
interpretation
of the law
Actual result
Simulated result
Generates
Results match?
Impact of fiscal
decisions
Simulates
Tax Law

4. Context and motivation
Analyzable
interpretation
of the law
4
Focus of the talk:!
What needs to be modeled?
What language to use?
What methodology to apply?

5. Related work
• Dutch legislation: UML Class Diagrams + OCL
[van Engers et al., 2001]
• US Internal Revenue Code: ontologies
[Melz et al., 2004]
• US healthcare: rule-based framework
[Breaux, 2009]
5

6. What are the differences?
• Modeling procedural & administrative aspects
!
!
!
!
•Support for automated verification in various form
!
6

7. Research steps
2. Build UML
profile
7
3. Use profile for
transforming
models
• What information
content should we
expect?
• What are the
complexity factors?
• Explicit means for
capturing information
requirements
• Basis for modeling
methodology
• Reuse existing
automation techniques
• Solvers for testing
• MATLAB for simulation
1. Conduct
grounded theory
study

8. What does the tax law look like?
• Legal framework composed of legislation,
regulations, and circulars
!
Art. 105bis […]The commuting expenses deduction (FD) is
defined as a function over the distance between the principal town
of the municipality on whose territory the taxpayer's home is
located and the place of taxpayer’s work. The distance is
measured in units of distance expressing the kilometric distance
between [principal] towns. A ministerial regulation provides these
distances.
!
The amount of the deduction is calculated as follows:
If the distance exceeds 4 units but is less than 30 units, the
deduction is € 99 per unit of distance.
The first 4 units does not trigger any deduction and the deduction
for a distance exceeding 30 units is limited to € 2,574.
• Framework has prescriptive nature
Procedure for
calculating FD
deduction
8
{{
Legal
concepts
definition

9. Meta-concepts in prescriptive laws
!
Grounded theory coding of 16 articles from Luxembourg’s
Income Tax Law
Art. 105bis […]The commuting expenses deduction (FD) is
defined as a function over the distance between the principal town
of the municipality on whose territory the taxpayer's home is
located and the place of taxpayer’s work. The distance is
measured in units of distance expressing the kilometric distance
between [principal] towns. A ministerial regulation provides these
distances.
!
The amount of the deduction is calculated as follows:
If the distance exceeds 4 units but is less than 30 units, the
deduction is € 99 per unit of distance.
The first 4 units does not trigger any deduction and the deduction
for a distance exceeding 30 units is limited to € 2,574.
9
Decision
Operation

10. Information requirements (1)
10
Datatype Set
Distance
1
Traceability Package
Legal
Text
Legal
Agent
Record
Information
Source
1..*
0..1
Process Package
Data Object
1..*
produces
as output
Step
1..*
has as
input
*
0..1
is derived from
originates from
Datatype Package
Numeric String
Boolean
Domain
Object
Age Percentage
Unit
Monetary
Value
Decision
Operation
Date
▶
▲
▶
▲
Legal Rule

11. Information requirements (2)
* 1
11
Datatype Set
Distance
Traceability Package
Legal
Text
Legal
Agent
Record
Information
Source
1..*
0..1
Process Package
Data Object
1..*
produces
as output
Step
1..*
has as
input
*
0..1
has as type
Datatype Package
Numeric String
Boolean
Domain
Object
Age Percentage
Unit
Monetary
Value
Decision
Operation
Date
▲ ▲
Legal Rule
▶

12. Information requirements (3)
* 1
12
Datatype Set
Distance
Traceability Package
Legal
Text
Legal
Agent
Record
Information
Source
1..*
0..1
Process Package
1..* has as type
Data Object
1..*
produces
as output
Step
1..*
has as
input
*
0..1
is derived from
originates from
Datatype Package
Numeric String
Boolean
Domain
Object
Age Percentage
Unit
Monetary
Value
Decision
Operation
Date
▶
▲
▶
▲
Legal Rule
▶
1

13. OCL complexity factors (1)
13
Numerous branches!
!
!
Art. 2 Individuals are
considered resident taxpayers
if they have their address in the
Grand Duchy. Individuals are
considered non-resident
taxpayers if they do not reside in
the Grand Duchy but have a
local income within the definition
of Article 156.
context TaxPayer inv ResidentialStatus:
let hasLocalAddress:Boolean = self.addresses! select(a:Address | a.country = Country::LU)
!notEmpty() in
if hasLocalAddress then
self.oclIsTypeOf(ResidentTaxPayer)
else
let hasLocalIncomes:Boolean = self.incomes! select(i:Income | i.oclIsTypeOf(LocalIncome))
!notEmpty() in
if hasLocalIncome then
self.oclIsTypeOf(NonResidentTaxPayer)
else
false
endif
endif

14. OCL complexity factors (2)
Art. 127 […]. An eligible dependent is a person who lives in the same
household as the taxpayer but is not taxpayer himself. Only dependent
receiving some allowances from the government are eligible.
self.taxPayerDependents!select(dependent:Person | not dependent.oclIsTypeOf(TaxPayer) and
dependent.addresses!intersection(self.addresses)!notEmpty() and
dependent.allowances.amount!sum>0)
14
Lengthy navigations!
!
!

15. OCL complexity factors (3)
Art. 127bis On request, the taxpayer
gets a deduction for extraordinary
expenses for children care. When
children under the age of twenty-one
are maintained and educated mostly by
the taxpayer, the total amount of all
expenses dedicated to these children is
considered as extraordinary expenses.
However, extraordinary expenses defined
by the current article must not exceed
3.480 euros per year and per child […]
15
Nested iterations
context TaxPayer inv CE3:
let tax year:Date = self.tax year,
incomes:Set(Income) = self.incomes! select(i:Income | i.year = tax year),
dependents:Set(Dependent) = self.dependents! select(d:Dependent | d.age < 21 )
in
incomes!forAll(inc:Income | dependents!forAll(dep:Dependent | let total expenses:MonetaryValue = inc.expenses! select(exp:Expense | exp.beneficiary = dep)!sum()
in
if total expenses < 3480 then
total expenses = inc.getCE3(tax year).amount
else inc.getCE3(tax year).amount = 3480 endif))

16. 2. Build UML
profile
16
3. Use profile for
transforming
models
Background: UML Profiles are a
standard mechanism to extend UML with
domain-specific modeling concepts
• What information
content should we
expect?
• What are the
complexity factors?
• Explicit means for
capturing information
requirements
• Basis for modeling
methodology
• Reuse existing
automation techniques
• Solvers for testing
• MATLAB for simulation
1. Conduct
grounded theory
study

17. Characteristics of our profile
Our UML profile:
!
• Customizes the activity modeling fragment of UML
!
!
• Provides stereotypes for capturing information
17
requirements
!
!
• Has built-in consistency constraints to ensure correct
use of the profile
!
!
!

18. Profile illustrated on an example
Art. 105bis […]The commuting expenses deduction (FD) is
defined as a function over the distance between the principal town
of the municipality on whose territory the taxpayer's home is
located and the place of taxpayer’s work. The distance is
measured in units of distance expressing the kilometric distance
between [principal] towns. A ministerial regulation provides these
distances.
!
The amount of the deduction is calculated as follows:
If the distance exceeds 4 units but is less than 30 units, the
deduction is € 99 per unit of distance.
The first 4 units does not trigger any deduction and the deduction
for a distance exceeding 30 units is limited to € 2,574.
18

19. OCL context
«rule» «context» TaxPayer
19

20. Decisions and operations (1)
«rule» «context» TaxPayer
«intermediate»
expected_amount
: MonetaryValue
20
«assert»
Check correctness of
deduction granted to taxpayer
«calculate»
No deduction
no (false)
«decision»
distance >
minimal_distance
«statement»
actual_amount =
expected_amount
«formula»
0 (zero)

21. Decisions and operations (2)
«rule» «context» TaxPayer
distance >
minimal_distance
distance <
maximal_distance
«calculate»
Normal rate per unit
for declared distance
«intermediate»
expected_amount
: MonetaryValue
21
«assert»
Check correctness of
prorata_period *
flat_rate * distance
deduction granted to taxpayer
«calculate»
No deduction
«formula»
yes (true)
yes (true)
no (false)
«decision»
«decision»
«statement»
actual_amount =
expected_amount
«formula»
0 (zero)

22. Decisions and operations (3)
«rule» «context» TaxPayer
distance >
minimal_distance
distance <
maximal_distance
«calculate»
Normal rate per unit
for declared distance
«intermediate»
expected_amount
22
no (false)
: MonetaryValue
«assert»
Check correctness of
prorata_period *
flat_rate * distance
deduction granted to taxpayer
«calculate»
No deduction
«calculate»
Special flat rate for
maximal distance
«formula»
yes (true)
yes (true)
no (false)
«decision»
«decision»
prorata_period *
maximal_flat_rate
«statement»
«formula»
actual_amount =
expected_amount
«formula»
0 (zero)

23. Iterations
«context» TaxPayer
distance >
minimal_distance
«calculate»
Normal rate per unit
for declared distance
«intermediate»
expected_amount
23
no (false)
: MonetaryValue
«assert»
Check correctness of
prorata_period *
flat_rate * distance
deduction granted to taxpayer
«rule»
«iterative»
inc : Income
«query»
Agent type: Officer
Question: When was
the request postmarked?
OCL: self.incomes->
select(i:Income|
i.year = tax_year)
«in»
«fromagent»
tax_year
«in»
incomes
distance <
maximal_distance
«fromrecord»
«calculate»
No deduction
«calculate»
Special flat rate for
maximal distance
«formula»
yes (true)
«query»
yes (true)
no (false)
«decision»
«decision»
prorata_period *
maximal_flat_rate
«statement»
«formula»
actual_amount =
expected_amount
«formula»
0 (zero)

24. Inputs (1)
«context» TaxPayer
distance >
minimal_distance
«calculate»
Normal rate per unit
for declared distance
«intermediate»
expected_amount
24
no (false)
: MonetaryValue
«assert»
Check correctness of
prorata_period *
flat_rate * distance
deduction granted to taxpayer
«rule»
«iterative»
inc : Income
«query»
Agent type: Officer
Question: When was
the request postmarked?
OCL: self.incomes->
select(i:Income|
i.year = tax_year)
«in»
«fromagent»
tax_year
«in»
incomes
distance <
maximal_distance
«fromrecord»
«calculate»
No deduction
«calculate»
Special flat rate for
maximal distance
«formula»
yes (true)
«query»
«query»
Source: Art. 105bis of
the LITL, 2013
OCL: inc.getFD
(tax_year).amount
«in» « fromlaw»
«in» « fromlaw»
maximal_flat_rate
«in»« fromlaw»
«in»« fromlaw»
«in»« fromrecord»
actual_amount
«query»
OCL: inc.prorata_period
«in»« fromrecord»
prorata_period
«query»
flat_rate
minimal_distance
maximal_distance
yes (true)
no (false)
«decision»
«decision»
prorata_period *
maximal_flat_rate
«statement»
«formula»
actual_amount =
expected_amount
«formula»
0 (zero)
«in»« fromrecord»
distance
«query»
OCL: inc.distance
Source: Ministerial
Regulation of February 6,
2012

25. «context» TaxPayer
distance >
Address
minimal_distance
TaxPayer
«calculate»
Normal rate per unit
for declared distance
«intermediate»
expected_amount
25
no (false)
: MonetaryValue
«assert»
Check correctness of
1
«enumera(on»
prorata_period *
flat_rate * distance
deduction granted to taxpayer
«rule»
«iterative»
inc : Income
«query»
Agent type: Officer
Question: When was
the request postmarked?
OCL: self.incomes->
select(i:Income|
i.year = tax_year)
«in»
«fromagent»
tax_year
«in»
incomes
distance <
maximal_distance
«fromrecord»
«calculate»
No deduction
«calculate»
Special flat rate for
maximal distance
«formula»
yes (true)
«query»
«query»
Source: Art. 105bis of
the LITL, 2013
OCL: inc.getFD
(tax_year).amount
«in» « fromlaw»
«in» « fromlaw»
maximal_flat_rate
«in»« fromlaw»
«in»« fromlaw»
«in»« fromrecord»
actual_amount
«query»
OCL: inc.prorata_period
«in»« fromrecord»
prorata_period
«query»
flat_rate
minimal_distance
maximal_distance
yes (true)
no (false)
«decision»
«decision»
prorata_period *
maximal_flat_rate
Constant
«statement»
«formula»
actual_amount =
expected_amount
«formula»
0 (zero)
«in»« fromrecord»
distance
«query»
OCL: inc.distance
Source: Ministerial
Regulation of February 6,
2012
IncomeTaxDeduction
- flat_rate
- maximal_flat_rate
- maximal_distance
- minimal_distance
*
* taxpayer
*
1 incomes
lives at
*
*
*
is accomplished at
1..*
CommutingExpense
Deduction
is based on
*
*
*
works at
Service
0..1 is paid for
Income
- distance:DistanceUnit
- prorata_period:Number
getFD(Date):MonetaryValue
1..*
Inputs (2)

26. Putting it together
26
1
«enumera(on»
Constant
no (false)
Address
TaxPayer
IncomeTaxDeduction
«context» TaxPayer
distance >
minimal_distance
«calculate»
Normal rate per unit
for declared distance
«intermediate»
expected_amount
: MonetaryValue
«assert»
Check correctness of
prorata_period *
flat_rate * distance
deduction granted to taxpayer
«rule»
«iterative»
inc : Income
«query»
{
Agent type: Officer
Question: When was
the request postmarked?
OCL: self.incomes->
select(i:Income|
i.year = tax_year)
«in»
«fromagent»
tax_year
«in»
incomes
distance <
maximal_distance
«fromrecord»
«calculate»
No deduction
«calculate»
Special flat rate for
maximal distance
«formula»
yes (true)
«query»
«query»
Source: Art. 105bis of
the LITL, 2013
OCL: inc.getFD
(tax_year).amount
«in» « fromlaw»
«in» « fromlaw»
maximal_flat_rate
«in»« fromlaw»
«in»« fromlaw»
«in»« fromrecord»
actual_amount
«query»
OCL: inc.prorata_period
«in»« fromrecord»
prorata_period
«query»
flat_rate
minimal_distance
maximal_distance
yes (true)
no (false)
«decision»
«decision»
prorata_period *
maximal_flat_rate
«statement»
«formula»
actual_amount =
expected_amount
«formula»
0 (zero)
«in»« fromrecord»
distance
«query»
OCL: inc.distance
Source: Ministerial
Regulation of February 6,
2012
- flat_rate
- maximal_flat_rate
- maximal_distance
- minimal_distance
*
* taxpayer
*
1 incomes
lives at
*
*
*
is accomplished at
1..*
CommutingExpense
Deduction
is based on
*
*
*
works at
Service
0..1 is paid for
Income
- distance:DistanceUnit
- prorata_period:Number
getFD(Date):MonetaryValue
1..*
Art. 105bis […]The commuting expenses
deduction (FD) is defined as a function over the
distance between the principal town of the
municipality on whose territory the taxpayer's
home is located and the place of taxpayer’s work.
The distance is measured in units of distance
expressing the kilometric distance between
[principal] towns. A ministerial regulation
provides these distances.
!
The amount of the deduction is calculated as
follows:
If the distance exceeds 4 units but is less than 30
units, the deduction is € 99 per unit of distance.
The first 4 units does not trigger any deduction
and the deduction for a distance exceeding 30
units is limited to € 2,574.
{

27. 2. Build UML
profile
27
3. Use profile for
transforming
models
• What information
content should we
expect?
• What are the
complexity factors?
• Explicit means for
capturing information
requirements
• Basis for modeling
methodology
• Reuse existing
automation techniques
• Solvers for testing
• MATLAB for simulation
1. Conduct
grounded theory
study

28. Transformation to OCL (1)
Activity Diagram
Retrieve all
required
inputs!
Declare!
Inputs!
28
Recognize !
Pattern!
Transform Pattern !
to OCL!
Make recursive call to handle next element !
«itera've»
iterator: Type
«in»+
Set(Object)
name:

29. Transformation to OCL (2)
Activity Diagram name ! forAll (iterator: Type |
Retrieve all
required
inputs!
Declare!
Inputs!
29
Recognize !
Pattern!
Filled by the algorithm’s unwinding
Transform Pattern !
to OCL!
)
Make recursive call to handle next element !

30. OCL vs. Model
1. context TaxPayer inv FD:
2. let tax year:Date = self.tax year in
3. let incomes:Set(Income) = self.incomes!select(i:Income | i.year = tax year) in
4. incomes!forAll(inc:Income | 5. let distance:DistanceUnit = inc.distance in
6. let minimal distance:DistanceUnit =
7. Constant::MINIMAL DISTANCE.oclAsType(DistanceUnit) in
8. if (distance > minimal distance) = true then
9. let maximal distance:DistanceUnit =
10. Constant::MAXIMAL DISTANCE.oclAsType(DistanceUnit) in
11. if (distance < maximal distance) = true then
12. let flat rate:MonetaryValue =
13. Constant::FLAT RATE.oclAsType(MonetaryValue) in
14. let prorata period:Numeric = inc.prorata period in
15. let expected amount:MonetaryValue = prorata period * flat rate * distance in
16. let actual amount:MonetaryValue = inc.getFD(tax year).amount in
17. actual amount = expected amount
18. else if (distance < maximal distance) = false then
19. let maximal flat rate:MonetaryValue =
20. Constant::MAXIMAL FLAT RATE.oclAsType(MonetaryValue) in
21. let prorata period:Numeric = inc.prorata period in
22. let expected amount:MonetaryValue = prorata period * maximal flat rate in
23. let actual amount:MonetaryValue = inc.getFD(tax year).amount in
24. actual amount = expected amount
25. else false endif
26. endif
27. else if (distance > minimal distance) = false then
28. let expected amount:MonetaryValue = 0 in
29. let actual amount:MonetaryValue = inc.getFD(tax year).amount in
30. actual amount = expected amount
31. else false endif endif
32. )
30

31. 2. Build UML
profile
31
3. Use profile for
transforming
models
• What information
content should we
expect?
• What are the
complexity factors?
• Explicit means for
capturing information
requirements
• Basis for modeling
methodology
• Reuse existing
automation techniques
• Solvers for testing
• MATLAB for simulation
1. Conduct
grounded theory
study

32. Evaluation of effort
We modeled the deductions and credits associated
with personal income taxes:
32
!
!
!
!
Deductions (12 ADs):!
• Commuting Expense !
• Miscellaneous Expenses !
• Spousal Expenses !
• Special Expenses!
• Extraordinary Expenses!
!
Credits (3 ADs):!
• Employment !
• Pension !
• Single parents
A Luxembourgish tax card

33. Models sizes
Resulting models have reasonable size
FD FO AC CE1 CE2 CE3 DS1 DS2 DS3 DS4 DS5 DS6 CIS CIP CIM
33
Number of elements
80
70
60
50
40
30
20
10
0
Activity Diagrams

34. Measured effort
Approximately 3.3 person-hour per activity diagram!
!
!
!
!
34
!
!
!
Effort spent to model deductions and credits for
personal income taxes:

35. Complexity reduction (1)
• AD tailored by our profile vs. manually-written OCL
!
• Metrics related to the identified complexity factors:
35
- Navigations
!
- If statements
!
- Operations on collections
!
- Iterative operations
[Reynoso et al., 2004]

36. Complexity reduction (2)
• AD tailored by our profile vs. manually-written OCL
!
• Metrics related to the identified complexity factors:
- Navigations: ↘ 45%!
36
!
- If statements: ↘ 100%!
!
- Operations on collections: ↘72%
!
- Iterative operations: ↘ 53%

37. Limitations
• Some complexity carries over to the models
!
• Specific to prescriptive legal frameworks
37

38. What’s next?
• User studies
!
• Extension to declarative legal frameworks
!
• Study how models built using our approach can
support simulation
38

39. context TaxPayer inv ResidentialStatus:
let hasLocalAddress:Boolean «context» TaxPayer
= self.addresses! select(a:Address | a.country = Country::LU)
Metrics related to the identified complexity
Datatype Set
factors:
Effort spent to model deductions and
credits for personal income Yes
taxes:
No
«query»
Agent type: Officer
Question: When was
the request postmarked?
1..* has as type
Data Object
1..*
has as
input
Test cases
Actual
software
system
«calculate»
No deduction
✗
1..*
«in»
«fromagent»
* 1
produces
as output
tax_year
«in»
- Navigations: «in» « fromlaw»
↘ 45%!
«in» « fromlaw»
maximal_flat_rate
«in»« fromlaw»
Approximately 3.3 person-hour
per «in»« fromlawactivity »
diagram!
«query»
Source: Art. 105bis of
the LITL, 2013
is derived from
Traces
minimal_distance
2. Build UML
profile
Traces
input to
input to
Analyzable
interpretation
of the law
Actual result
distance >
simulated result
Generates
Distance
Results match?
«calculate»
Normal rate per unit
for declared distance
«intermediate»
prorata_period *
flat_rate * distance
Impact of fiscal
decisions
Simulates
Tax Law
«in»« fromrecord»
«in»« fromrecord»
«in»« fromrecord»
30
3. Use profile for
transforming
models
• What information
content should we
expect?
• What are the
complexity factors?
• Explicit means for
capturing information
requirements
• Basis for modeling
methodology
• Reuse existing
automation techniques
• Solvers for testing
• MATLAB for simulation
1. Conduct
grounded theory
study
Traceability Package
Legal
Text
Legal
Agent
prorata_period *
maximal_flat_rate
Record
expected_amount
Information
Source
1..*
0..1
Process Package
Step
*
0..1
originates from
Datatype Package
Numeric String
Boolean
Domain
Object
Age Percentage
Unit
Monetary
Value
Decision
Operation
Date
▶
▲
▶
▲
Legal Rule
▶
1
!notEmpty() in
if hasLocalAddress then
self.oclIsTypeOf(ResidentTaxPayer)
else
let hasLocalIncomes:Boolean = self.incomes! select(i:Income | i.oclIsTypeOf(LocalIncome))
!notEmpty() in
if hasLocalIncome then
self.oclIsTypeOf(NonResidentTaxPayer)
else
false
endif
endif
no (false)
: MonetaryValue
«assert»
Check correctness of
deduction granted to taxpayer
«rule»
«iterative»
inc : Income
OCL: self.incomes->
select(i:Income|
i.year = tax_year)
incomes
distance <
maximal_distance
«fromrecord»
«calculate»
Special flat rate for
maximal distance
«formula»
yes (true)
«query»
OCL: inc.getFD
(tax_year).amount
actual_amount
«query»
OCL: inc.prorata_period
prorata_period
«query»
flat_rate
minimal_distance
maximal_distance
yes (true)
no (false)
«decision»
«decision»
«statement»
«formula»
actual_amount =
expected_amount
«formula»
0 (zero)
distance
«query»
OCL: inc.distance
Source: Ministerial
Regulation of February 6,
2012
Summary
39
!
!
!
!
!
- If statements: ↘ 100%!
!
- Operations on collections: ↘72%
!
- Iterative operations: ↘ 53%

40. Using UML for Modeling Procedural
Legal Rules
Approach and a Study of Luxembourg’s Tax Law!
Ghanem Soltana!
ghanem.soltana@uni.lu!
http://people.svv.lu/soltana/
SsoftwareV verificVation & va.lidlaution
University of Luxembourg, Luxembourg!

41. Acknowledgements
• CTIE: Ludwig Balmer, Marc Blau, Yves Boland,
Michaël Masseroni, Gautier Barrère
• ACD: Thierry Prommenschenkel, Guy Heintz,
Vincent D'Angelo
• SnT: Domenico Bianculli
41

42. Modeling methodology
42
Relevant Legal
Texts
Feedback
Analysis
Model the domain
Model legal rules
Domain Model
Formal Specification
ADToOCL
Transformation
UML Profile
adequate input
Activity Diagram
(legal rule)
OCL