Modeling behavioral deontic constraints using UML and OCL

Modeling behavioral deontic
constraints using UML and OCL
Antonio Vallecillo, Martin Gogolla
Universidad de Málaga, Spain
University of Bremen, Germany
Link to the paper: https://doi.org/10.1007/978-3-030-62522-1_10

What is deontic logic?
 What is deontic logic?
 Deontic logic is the logic of Ethics
 It is about what is permissible and what is obligatory:
 What we should and should not do
 What we are allowed to do, and what we are not allowed to do
 What are deontic constraints?
 Deontic constraints are the way of expressing how a digital system is used and
applied in the real world so that moral or business rules are respected
 “Alethic” vs. “Deontic” rules
 Alethic rules impose “necessities” that cannot be violated (e.g. the age of a
person cannot be negative)
 Deontic rules impose “obligations” that can be violated although they should not
(e.g., borrowed books must be returned within one week).
 Accountability
 System actors or agents must be liable for their actions or inactions, whenever
they do not fulfil their obligations or transgress the system rules
2

Use of Deontic logic in systems specifications
 Allows us to deal with norms and expectations
 Obligations to perform specified behaviour
 Permissions to perform such behaviour
 Prohibitions of certain behaviours
 We shift to a style of specification where the focus is not only on the concrete
steps and processes, but on
 a set of obligations that must be discharged;
 who is responsible for discharging them;
 who is allowed to do that, and when;
 Delegation of obligations and permissions is possible
 Liability can be traced in case of problems, and parties become accountable
for their actions (and for their inactions!)
3

The current situation
 Some modeling proposals and notations, such as SBVR, ORM or the
Enterprise Language of the RM-ODP, provide support for deontic concepts
 Effectively used, e.g., in the e-Health domain! [19,20]
 Based on modal logics
 Using declarative approaches, which require specialized knowledge and with
little tool support (at most for editing, no proper analysis tools )
4
[13] [16]

Our contribution in this paper
 A proposal to explicitly specify dynamic (behavioral) deontic constraints in
UML and OCL
 They can be used to guide and restrict the behavior of the system, and
 They allow deontic reasoning about such a behavior, including accountability
analysis
 Operational style of specification, based on
(a) Deontic tokens,
 They reify deontic permissions and obligations as objects (permits and burdens)
 They can be explicitly handled in pre- and postconditions of operations
(b) Filmstrip models,
 They reify the system actions as objects so the system behavior is represented as
sequence of snapshots, and behavioral constraints become structural invariants
5

Case study: a student grading system
6

Some deontic constraints
1. Students are permitted to register with any teacher who does not have a
report from them that is still pending to grade
2. Students registered with a teacher have the permission, and the obligation,
to deliver the report to that teacher
3. Teachers have the permission, and the obligation, to grade all reports that
they advise and that are delivered to them
4. Students are permitted to view only the marks of their reports, and only
once these have been graded
5. Teachers are permitted to view only the marks of the reports they have
graded, but only once they have given the mark
7

Filmstrip models
 Permit the specification of behavior as a sequence of snapshots
 Each snapshot describes the current state of the system at one moment
 Transitions are caused by operation calls (in our current proposal)
8

A filmstrip object model with five snapshots (after 4 operations)
 Filmstrips provide a structural (static) specification of (dynamic) behavior!
 They allow the use of structural analysis tools for deontic reasoning
 Pre- and postconditions of operations become invariants in the filmstrip
 In USE, filmstrips can be automatically derived from behavioral specifications!
9

Reification of deontic tokens as objects
 Obligations reified as “Burdens”
 Permissions reified as “Permits”
 Agents acquire and release “permits” and “burdens” along their lifetime
10ISO/IEC 19793, ITU-T Rec. X.906: Information technology – Open distributed processing – Use of UML for ODP system specifications. (2015)

Combining filmstrips and deontic tokens
11

A filmstrip showing how deontic tokens evolve along the execution
12

Tokens are used in pre- and post conditions of operations!
 They specify how tokens are required for an action to proceed, and how they
are acquired/released as a result of the action
13

And now?
 Two possible model execution/simulation approaches:
 Prescriptive (deterministic): selecting a sequence of actions and executing them
in order
 Descriptive (non-deterministic): Continuously choosing one of the possible
actions that can be executed (i.e., whose pre-conditions are fulfilled) until no
further action is enabled
 Dynamic Analysis on the system can be accomplished by means of static
analysis on the filmstrip models:
 Temporal properties
 Fairness
 Reachability analysis
 Deontic constraints independence
 Accountability analysis
14

Temporal properties
 E.g., valid sequences of operations
(Student::register) -> (Student::deliver) -> (Teacher::grade) ->
[ (Student::viewMark) | (Teacher::viewMark) ]+
 Simply expressed as structural invariants on filmstrips:
15

Reachability analysis
 The USE model validator can be used to automatically find valid filmstrips
(i.e., behaviors) that starting from a configuration that can lead to a given
state (specified by an invariant)
16

Accountability analysis
 Agents can be tracked when undesirable situations happen
 Deadlocks: Agents with burdens to perform actions but with no permits for
them
 Rule transgression: Actions performed by agents with no permits for them
 They all can be checked using OCL expressions
 For example, no further burden remains undischarged in the system:
17

Conclusions and future work
 Explicit representation of the deontic rules and
tokens
 Instead of their implicit representation as
formulas in a modal logic, which might be
more difficult to debug, implement and maintain
 UML models with deontic tokens can be simulated to detect undesirable
situations ranging from constraint violations to deadlocks or starvation
 E.g., due to lack of permissions or non-dischargeable burdens.
 We achieve the necessary separation of concerns
 to decouple the functional specifications of a system from the deontic rules that
are applicable to it at a given moment, since the latter can evolve over time.
18

Conclusions and future work
 More case studies and Usability experiments
 Specification of “Delegations”
 They may require further “permissions to delegate” and might seriously
complicate accountability analysis
 Pessimistic enforcement model (actions are forbidden unless they are
explicitly permitted)
vs. optimistic enforcement model (actions are permitted unless explicitly
prohibited)
 Mappings to other modeling notations (SBVR, ORM, …)
19

Modeling behavioral deontic constraints using UML and OCL