using uml for modeling procedural legal rules: approach and a study of luxembourg’s tax law ghanem...
TRANSCRIPT
Using UML for Modeling Procedural Legal Rules: Approach and a Study of
Luxembourg’s Tax LawGhanem Soltana, Elizabeth Fourneret, Morayo Adedjouma, Mehrdad Sabeztzadeh and
Lionel BriandSnT Centre for Security,Reliability and trust, University of Luxembourg, Luxembourg
Presented By: Suchita Ganesan
Outline
• Motivation• Abstract• Overview of the paper• Strengths of the Paper• Limitations of the Paper• Conclusion
Issue
• Legal compliance is a major concern for the governments• Example (Article 2 from Luxembourg’s Income Tax Law)Individuals are considered resident tax payers if they have their address in the Grand Duchy but have a local income within the definition of Article 156.• Necessity to analyze whether a software system complies
with the tax payer classification described in the law• Legal frameworks are often prescriptive
Focus of the paper!
What needs to be modeled?
Test cases
Actualsoftwaresystem
Traces to
What language to use?What methodology to apply?
Results match?
Generates
Traces to
Analyzableinterpretationof the law
Simulates
✗
Impact of fiscal decisionsTax Law
Context and Motivation
• Collaboration withGovernment ofLuxembourg
• CTIE: Government’s IT Centre
• ACD: Tax Administration Department
• New tax system under development
• System needs to be compliant with the law
How did this work come about?
Abstract
• UML based approach for modeling procedural legal rules
• Investigate legal texts with help from legal experts to identify both the information needs and sources of complexity in formalization of procedural legal rules
• Develop a UML profile which enables precise modeling of procedural legal rules
• Transform models into the Object Constraint Language(OCL)
Research Steps
1. Conduct grounded
theory study
2. Build UML Profile
3. Use Profile for Transforming
Models
• Complexity factors• Information Content
• Means of capturing Information Requirements
• Basis of modeling methodology
• Reuse existing automation techniques
• Solvers for testing
Conduct Grounded theory Study
• Apply GT process to define1. What needs to be expressed in models of
legal rules (Information Requirements)2. Complexity Factors- Navigation- Branching- Iteration
What does the tax law look like?
• The meta-concepts gleaned from the exerpt are shaded and labeled• Each Rule is made up of a set of Operations and Decisions describing
the flow of a rule• There are several data elements in the excerpt
Information requirements (1)
Information requirements (2)
Information Model for Legal Rules
OCL complexity factors (1)
OCL complexity factors (2)
OCL complexity factors (3)
Modeling Methodology
• Complexity factors• Information Content
• Means of capturing Information Requirements
• Basis of modeling methodology
• Reuse existing automation techniques
• Solvers for testing
• Customizes the Activity Modeling Fragment of UML• Provides stereotypes for capturing information
requirements• Has built-in consistency constraints to ensure correct
use of the profile
Characteristics of UML Profile
Profile illustrated on an example
OCL context«rule» «context» TaxPayer
Decisions and operations (1)«rule» «context» TaxPayer
«decision»distance >
minimal_distance
«intermediate»expected_amount
: MonetaryValue
«formula»0 (zero)
«calculate»no (false)No deduction
«assert» «statement»Check correctness of actual_amount =
deduction granted to taxpayer expected_amount
Decisions and operations (2)«rule» «context» TaxPayer
«decision»distance >
minimal_distance
yes (true)
«decision»distance <
maximal_distance
yes (true)
«calculate»Normal rate per unitfor declared distance
«intermediate»expected_amount
: MonetaryValue
«formula»0 (zero)
«calculate»no (false)No deduction
«formula»
prorata_period *flat_rate * distance
«assert» «statement»Check correctness of actual_amount =
deduction granted to taxpayer expected_amount
Decisions and operations (3)«rule» «context» TaxPayer
«decision»distance > no (false)
minimal_distance
yes (true)
«decision»distance < no (false)
maximal_distance
yes (true)
«formula»0 (zero)
«calculate»
No deduction
«calculate»
Special flat rate formaximal distance
«formula»«calculate»
Normal rate per unitfor declared distance
«intermediate»expected_amount
: MonetaryValue
«formula»
prorata_period *flat_rate * distance
prorata_period *maximal_flat_rate
«assert» «statement»Check correctness of actual_amount =
deduction granted to taxpayer expected_amount
Iterations«query»
Agent type: OfficerQuestion: When was
the request postmarked?
«query»OCL: self.incomes->
«rule» «context» TaxPayer
«in»«fromagent» «iterative»tax_year
inc : Income«
decision»«in»«fromrecord»
«formula»0 (zero)
«calculate»
select(i:Income| incomesi.year = tax_year)
distance > no (false)
minimal_distance
yes (true)
«decision»distance < no (false)
maximal_distance
yes (true)
No deduction
«calculate»
Special flat rate formaximal distance
«formula»«calculate»
Normal rate per unitfor declared distance
«intermediate»expected_amount
: MonetaryValue
«formula»
prorata_period *flat_rate * distance
prorata_period *maximal_flat_rate
«assert» «statement»Check correctness of actual_amount =
deduction granted to taxpayer expected_amount
Inputs (1)«query»
Agent type: OfficerQuestion: When was
the request postmarked?
«query»OCL: self.incomes->
«rule» «context» TaxPayer
«in»«fromagent» «iterative»tax_year
inc : Income«
decision»«in»«fromrecord»
«formula»0 (zero)
«calculate»
select(i:Income|i.year = tax_year)
«query»Source: Art. 105bis ofthe LITL, 2013
incomes
«in»«fromlaw»flat_rate
«in»«fromlaw»maximal_flat_rate
«in»«fromlaw»minimal_distance
distance > no (false)
minimal_distance
yes (true)
«decision»distance < no (false)
maximal_distance
yes (true)
No deduction
«calculate»
Special flat rate formaximal distance
«formula»
«query»OCL: inc.getFD
(tax_year).amount
«query»OCL: inc.prorata_period
«query»
«in»«fromlaw»maximal_distance
«in»« fromrecord»actual_amount
«in»« fromrecord»prorata_period
«calculate»Normal rate per unitfor declared distance
«intermediate»expected_amount
: MonetaryValue
«formula»
prorata_period *flat_rate * distance
prorata_period *maximal_flat_rate
OCL: inc.distance
Source: MinisterialRegulation of February 6,2012
«in»«fromrecord»distance
«assert»Check correctness of
deduction granted to taxpayer
«statement»actual_amount =
expected_amount
Inputs (2)«query»
Agent type: OfficerQuestion: When was
the request postmarked?
«query»OCL: self.incomes->
select(i:Income|
«rule» «context» TaxPayer
«in»«fromagent» «iterative»tax_year
«in»«fromrecord»incomes is accomplished at Service
i.year = tax_year)
«query»Source: Art. 105bis of
«in»«fromlaw»flat_rate
«in»«fromlaw»maximal_flat_rate
Address
*lives at works at
1
TaxPayer
1..*
incomes 1..*taxpayer
*
*1
0..1 is paid for
Income- distance:DistanceUnit- prorata_period:NumbergetFD(Date):MonetaryValue
*the LITL, 2013
«in»«fromlaw»is based on
minimal_distance
«in»«fromlaw»«query» maximal_distance
*
IncomeTaxDeduction*
«enumera(on»Constant
OCL: inc.getFD(tax_year).amount
«query»OCL: inc.prorata_period
«query»
OCL: inc.distance
Source: MinisterialRegulation of February 6,2012
«in»« fromrecord»actual_amount
«in»« fromrecord»prorata_period
«in»«fromrecord»distance
CommutingExpenseDeduction
- flat_rate- maximal_flat_rate- maximal_distance- minimal_distance
Putting it togetherArt. 105bis […]The commuting expenses is accomplished at
Address 1..* *Service
1deduction (FD) is defined as a function over thedistance between the principal town of the lives at
* *
*
works at1 incomes
taxpayer
0..1 is paid for
Income1..*
- distance:DistanceUnit
municipality on whose territory the taxpayer'sTaxPayer * - prorata_period:Number
getFD(Date):MonetaryValue
*
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 providesthese distances.!
*
IncomeTaxDeduction
CommutingExpenseDeduction
is based on
*«enumera(on»Constant
- flat_rate- maximal_flat_rate- maximal_distance- minimal_distance
The amount of the deduction is calculated asfollows:
«query»Agent type: OfficerQuestion: When was
the request postmarked?
«query»OCL: self.incomes->
«rule» «context» TaxPayer
«in»«fromagent» «iterative»tax_year
inc : Income«
decision»«in»«fromrecord»
«formula»0 (zero)
«calculate»
If the distance exceeds 4 units but is less than 30units, the deduction is € 99 per unit of distance.The first 4 units does not trigger any deduction
select(i:Income|i.year = tax_year)
«query»Source: Art. 105bis ofthe LITL, 2013
incomes
«in»«fromlaw»flat_rate
«in»«fromlaw»maximal_flat_rate
«in»«fromlaw»minimal_distance
distance > no (false)minimal_distance
yes (true)
«decision»distance < no (false)
maximal_distance
yes (true)
No deduction
«calculate»
Special flat rate formaximal distance
«formula»
and the deduction for a distance exceeding 30units is limited to € 2,574.
«query»
OCL: inc.getFD(tax_year).amount
«query»OCL: inc.prorata_period
«query»
OCL: inc.distance
Source: MinisterialRegulation of February 6,2012
«in»«fromlaw»maximal_distance
«in»« fromrecord»actual_amount
«in»« fromrecord»prorata_period
«in»«fromrecord»distance
«calculate» «formula» prorata_period *Normal rate per unit prorata_period * maximal_flat_rate
for declared distance flat_rate * distance
«intermediate»expected_amount
: MonetaryValue
«assert» «statement»Check correctness of actual_amount =
deduction granted to taxpayer expected_amount
3. Use profile fortransforming
models
2. Build UMLprofile
1. Conductgrounded theory
study
requirements
• Complexity factors• Information Content
• Means of capturing Information Requirements
• Basis of modeling methodology
• Reuse existing automation techniques
• Solvers for testing
Transformation to OCL (1)
«itera've»Activity Diagram
iterator: Type«in»+name:
RecognizePattern
Retrieve allrequiredinputs!
Set(Object)
DeclareInputs
Transform Patternto OCL
Make recursive call to handle next element !
Transformation to OCL (2)
Activity Diagram
RecognizePattern
Retrieve allrequiredinputs!
name ! forAll (iterator: Type |
Filled by the algorithm’s unwinding
)
DeclareInputs
Transform Patternto OCL
Make recursive call to handle next element !
OCL vs. Model1. context TaxPayer inv FD:2. let tax year:Date = self.tax year in3. let incomes:Set(Income) = self.incomes!select(i:Income | i.year = tax year) in4. incomes!forAll(inc:Income |5. let distance:DistanceUnit = inc.distance in6. let minimal distance:DistanceUnit =7. Constant::MINIMAL DISTANCE.oclAsType(DistanceUnit) in8. if (distance > minimal distance) = true then9. let maximal distance:DistanceUnit =10. Constant::MAXIMAL DISTANCE.oclAsType(DistanceUnit) in11. if (distance < maximal distance) = true then12. let flat rate:MonetaryValue =13. Constant::FLAT RATE.oclAsType(MonetaryValue) in14. let prorata period:Numeric = inc.prorata period in15. let expected amount:MonetaryValue = prorata period * flat rate * distance in16. let actual amount:MonetaryValue = inc.getFD(tax year).amount in17. actual amount = expected amount18. else if (distance < maximal distance) = false then19. let maximal flat rate:MonetaryValue =20. Constant::MAXIMAL FLAT RATE.oclAsType(MonetaryValue) in21. let prorata period:Numeric = inc.prorata period in22. let expected amount:MonetaryValue = prorata period * maximal flat rate in23. let actual amount:MonetaryValue = inc.getFD(tax year).amount in24. actual amount = expected amount25. else false endif26. endif27. else if (distance > minimal distance) = false then28. let expected amount:MonetaryValue = 0 in29. let actual amount:MonetaryValue = inc.getFD(tax year).amount in30. actual amount = expected amount31. else false endif endif32. )
3. Use profile fortransforming
models
2. Build UMLprofile
1. Conductgrounded theory
study
requirements
• Reuse existing
• Complexity factors• Information Content
• Means of capturing Information Requirements
• Basis of modeling methodology
• Reuse existing automation techniques
• Solvers for testing
Evaluation
1. Is the approach enough to model complex legal rules?
2. Is the level of effort required by our approach reasonable?
3. Are the Activity Diagrams built using our approach structurally less complex than OCL constraints written directly?
Related Work
• Legal Rules• Verification of Legal Compliance• Visualization of Logical Languages• Model-to-OCL Transformation
Strengths of the Paper
• Very Interesting• Well Written paper in a coherent manner• Motivation behind paper• Clear examples and well explained• Segregation of Sections improved readability• Informative Introduction
Limitations of the Paper
• Evaluation of approach not strong• Navigating to the References• Limited to only prescriptive legal frameworks
Conclusions
• UML based approach for modeling procedural legal rules. The key component of the approach is a profile for activity diagrams. To enable automated compliance analysis, they defined a transformation that produces OCL specifications from activity diagrams built using the profile.
• They presented a preliminary evaluation of their approach
