Modeling behavioral deontic constraints using UML and OCL
1. 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
2. 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
3. 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
4. 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]
5. 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
7. 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
8. 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
9. 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
10. 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)
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
Notas do Editor
Our work aims at addressing this drawback by allowing modelers to specify deontic concepts and rules in plain UML and OCL, using an operational style (instead of a declarative one), based on two main pillars:
The reification of deontic permissions and obligations as objects, which are assigned to the system active objects
The reification of actions as objects, that “link” their corresponding “before” and “after” system states. Thus, a filmstrip is a sequence of models (snapshops) linked by the action occurrences that cause the system state changes.
In this way, behavioral constraints become structural invariants in a filmstrip.