Accountable objects: Modeling Liability in Open Distributed Systems

Accountable objects:
Modeling Liability in Open
Distributed Systems

Antonio Vallecillo
Universidad de Málaga
Vienna, January 28, 2013
[Joint work with Peter F. Linington
and Hiroshi Miyazaki at ISO/IEC]

The Supply of Olive Oil

We use a very simple e-commerce example to explore
these ideas:
A business (The Modern Oil
Store) acts as a supply channel
from producers to customers
It uses external contractors to
perform deliveries
The buyer pays on receipt of the
oil

A.Vallecillo: "Accountable Objects: Modeling Liability in Open Distributed Systems" Vienna, 2013 2

Main Characters (Roles)

Customer Supplier

Producer Carrier

The Supply of Olive Oil

Imagine that at one given moment in time, the supply
process does not work as specified by the contract,
e.g., the olive is not delivered
to the customer
Maybe the supplier forgot to
instruct the producer;
Maybe the producer did not
produce the goods;
Maybe the carrier could not
pickup from the producer;
…

Who is accountable for what?
Who is to be sued in case of losses?

Use of Deontic Logic in system specs

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 [in]actions

Background

Activity within the ODP family of
standards

Work is centred within ISO as an
extension to the ODP Enterprise
Language and UML4ODP
standards

Improve support for deontic
concepts


Timeline

Based on ideas published in 2003 (Linington & Neal)
Project to incorporate into the ODP standards first
mooted in 2007
Initial study phase to scope and set direction
Full project approval 2011
1st full draft for revised Enterprise Language balloted
June 2012

ISO Standards take upward compatibility very seriously
Changes must be made in such a way that other
standards in the family are not invalidated
Revisions of particular standards may motivate alignment
changes in dependent or supporting standards


ODP Framework
The Reference Model of ODP (ITU-T Rec X.901-904 |
ISO/IEC 10746) defines a framework for system
specification, covering all aspects of ODS:
“enterprise”, data, functionality, distribution, technology
It comprises
A structure for system specifications in terms of a set of
viewpoints
A set of object-oriented foundation modeling concepts
common to all viewpoint languages
A viewpoint language (concepts and rules) for
expressing each viewpoint specification
A set of correspondences between the viewpoints
A set of common functions
A set of transparencies
A set of conformance points


ODP Viewpoints

Different abstractions of the same system
each abstraction focuses on different concerns
each abstraction is achieved using a
set of viewpoint concepts and rules
(the viewpoint language)

A viewpoint specification is
the specification of a system from a specific viewpoint
expressed in terms of the viewpoint language to
describe the concerns and decisions covered by the
viewpoint specification
related to, and consistent with, other viewpoint
specifications (correspondences)


An ODP system specification

- business aspects Enterprise
- What for? Why? Who? When?

- information
- changes to information Information
- constraints
- object configuration
- Interactions between Computational
objects at interfaces
- mechanisms and services
for distribution trans-
parencies and QoS constraints. Engineering

- hardware and software components Technology
implementing the system

- and correspondences between specifications

The “Enterprise” Viewpoint

The enterprise viewpoint focuses on the specification of
the business constraints and the environment
within which an ODP system is to operate
It describes the business entities and the processes
to be considered.
It provides a place to express general organizational
policies that constraint the other viewpoints and
stakeholders
One “enterprise”…
…may be a single organization
…may be describing an ad hoc grouping
…may be a loose social group
…may be a legal jurisdiction
…may be a federation

The enterprise language
Specifies the roles played by the system in its
organizational environment

An object model of, for example, part of some
social/commercial organization in terms of:
Communities (of enterprise objects) with objectives
Enterprise objects
Behaviour
Roles (fulfilled by enterprise objects in a community)
Processes (leading to objectives)
Policies
Accountability

The IT system is just another object


Communities

Configuration of objects with a stated purpose
Objects participate by filling typed roles
Community behaviour is expressed as recursive
composition of interactions between roles
Constraints on role filling can be used to express e.g.
dynamic separation of duties
Community type seen as the community “contract”

Examples
The Olive Oil community
A University
A Library


Roles

Roles provide an essential way of expressing the way in
which fragments of specification are composed to form
a whole
Particularly as an aid to the reuse of a fragment in a number of
situations within the specification
Underlying metaphor is the filling of roles defined in a script to
describe a performance…
…or filling formal parameters with actual terms in a language –
e.g. in a procedure
Active roles (actors), passive roles (artefacts)
Examples
Customer, Supplier, Carrier, Goods,…
Teacher, Student, Classroom, …
Librarian, Library member, Book…


Interactions

• Interactions involve a number of participants
• Model as the filling of action-roles by objects
• Express action types using action roles as their formal
parameters


How to deal with Obligations,
Permissions and Prohibitions?

Dynamics of Obligations

• The main idea is that systems evolve by interactions
resulting in the creation, transfer or destruction of
obligations

• Reify obligations as deontic tokens, which are first-class
objects held by actors in the system

• Tokens can be used in expressing
Obligations (Burdens)

Permissions (Permits)

Prohibitions (Embargos)


The Enterprise specification

The e-commerce system will be specified by one single
community

Its goal is to “act as supply channel from producers
customers”

Its objects model the community entities: people (“Joe
Smith”, “Lucy Brown”), companies (“LaEspañola”), items
(olive oil bottle#123), purchase order#999, etc.

Its basic roles are:
Customer, who wants the oil and will pay for it
Supplier, the Modern Oil Company
Producer, one of a group of participating farmers
Carrier, who take the oil from supplier to customer

Its processes include Purchase, Return defective lot, etc.


Enterprise specification (ct’d)
Assignment policies (e.g., the requirements of a person or
a company to become a customer)

Policies:
Permissions: what can be done, e.g. the customer can buy
from the supplier
Prohibition: what must not be done, e.g. individual customers
must not buy directly from the producer
Obligations: what must be done, e.g. the supplier must
deliver the goods to the customer; the customer must pay 30
days after delivery of goods.
Authorizations: regular customers are entitled to have
discounts and to pay up to 60 days after delivery
Delegations: suppliers can use external carrier companies to
deliver the goods to the customers


The Basic “Purchase” Process

Community Roles in an
individual purchase
transaction:
Customer, who wants
the oil and will pay for it
Supplier, the Modern Oil
Company
Producer, one of a group
of participating farmers
Carrier, who take the oil
from supplier to
customer


Tokens Involved

At each stage in a transaction tokens may be:
Needed from some roles as input
Created by an interaction
Passed to roles in the interaction
Discharged or cancelled
Maintained

These changes can capture the details we want to
specify in a concise way
Authorization to proceed
Delegations of responsibility
Discharge of obligations
Release of duties


The “Order” Interaction

Permit supplied by customer, burdens created

Place
order
pay on supply
delivery oil

order()

customer supplier customer supplier


The “InstructProducer” Interaction

Subcontracting moves tokens, creates others

pay
producer produce
oil goods
supply oil
supply oil produce
oil goods
monitor produce
delivery oil
instruct()

supplier producer supplier producer


The “InstructSupplier” Interaction
[Note: payment extends behaviour given]

pay Deliver oil
carrier
collect oil
monitor deliver
delivery oil monitor
delivery pickup oil

instruct()

supplier carrier supplier carrier


The “Report” Interaction

Finalizes both subcontracts; some permits remain

Deliver oil

supply
charge Deliver oil
oil deliver oil customer

report()

supplier carrier supplier carrier


The “Charge” Interaction
[Note: The charge interaction is seen here as binary; there is probably
a hidden involvement of a bank]

pay on charge transaction
delivery customer complete!
charge()

customer supplier customer supplier


Patterns of Token Use
Unique tokens for individual actions/artefacts vs.
Universal tokens for types of actions/artefacts
Permit to deliver one box of olive oil
Permit to carry goods (in general)

Implicit tokens vs. Explicit tokens
Permits by default and explicit prohibitions vs.
Explicit permits and prohibitions by default
Economy of the language/”By default” policy

Full delegation vs. No delegation vs. Monitoring
We can model different strategies depending on the system we
want to represent/specify
Delegation may require permissions, too


Simple Tokens

Consider one active object and the tokens it carries:

object

burden

permit


More Complex Situations

There may be many tactics:


Community Burdens

• Need to have a community has burden
compact way of
showing how tokens community
pass to objects
filling community community assigns
roles burden to role
• Need to show role
recovery from
exceptions
object fills role,
inherits burden

object’s enterprise object
other burdens

Inheritance of Tokens

One of the open issues is whether it is more powerful to
talk of assigning tokens to roles rather than objects

Token automatically reverts to community, associated
with empty role, if role-filling object fails
But is this too abrupt?
Is it too complex?


Notations and tools

How to express these concepts and mechanisms in the
specification of systems?

The real issue is what the tools available in practice will
support!

Different options still being studied to see what
practitioners find acceptable


UML Mapping

ISO 19793 – UML4ODP provides a concrete
representation for ODP models

Each viewpoint language has a profile defined in terms
of a set of UML stereotypes

We extend this to add the new concepts, e.g.
Deontic Tokens
Active Objects
Conditional Actions


Changing The Enterprise Language Metamodel

Placing the specification in context.


Core Community Definitions


Behavioural Definitions


Deontic Framework


Token Lifecycle

Most behaviour is enterprise-specific
Provide minimal lifecycle behaviour as root


The Olive Oil Community


The “Purchase” Process


The “Order” interaction


The complete community


The “Order” interaction


The “InstructProducer” interaction


Issues of Style
Flexible and Expressive approach
Still many open ways to model liability in UML4ODP

No approach fits all purposes
Different ways to model obligations, depending on the
particular system
Delegations and monitoring of responsibilities depends on the
kinds of analysis to be conducted

Usability and Readability of diagrams and specifications
essential for proper specification and maintainability

UML tool support for analysis and simulation still insufficient


A BPMN Mapping?

UML is not the only show in town

Interest in mapping the same conceptual structure onto
other languages and notations

Primary candidate for a second mapping is BPMN

Progression depends on the level of support and
contribution

Likely to need a new project in ISO


Rule-based DSLs

DSLs can provide more effective solutions

Such as eMotions…


Simulations

[Spanshot after 50 simulation steps]

The Importance of Tools
There is a symbiotic relationship between users,
standardizers and tool vendors

Often the tool vendors lag behind current modelling ideas

But without tools, ideas cannot be used in practice

Validation of additional semantic constraints can be added via
plug-ins, but this is a single tool solution

Tool support for Behavioural Specifications still in its infancy


Further Questions


What is an Obligation?

So far, we have assumed it is obvious what a deontic
constraint, such as an obligation means

Need to establish a formal semantic basis

Other views, e.g. Computational, have used
correspondences to a labelled transition system

This focuses on correctness of a move to the direct
successor state


Providing a Broader View

Deontic concepts need to be defined in terms of
properties of possible successor traces

Need to evaluate across properties of sequence of
successor worlds (trace)

One approach is to base interpretation on
correspondences to a set of Kripke frames

But can this be normative? Currently included as an
informative discussion


Next Steps

ISO 15414 – The Enterprise Language
CD Ballot complete, comments resolved at November
meeting
FCD in preparation
No obvious show-stoppers

19793 – UML4ODP
Start November 2012, offset by 12 months from 15414
Preliminary planning and directions document produced
WD in preparation

Currently internal ISO drafts
Contact peter@linington.eu or av@lcc.uma.es for copies


References
P. F. Linington, H. Miyazaki and A. Vallecillo. “Obligations and
Delegation in the ODP Enterprise Language.” In Proc. of VORTE
2012 (EDOC Workshops), IEEE Computer Society, Sept 2012, pp.
146-155. http://www.lcc.uma.es/~av/Publicaciones/12/edoc-
tokens.pdf

P. F. Linington and S. Neal, “Using policies in the checking of
business to business contracts.” In Proc. of the 4th IEEE Int. Work.
on Policies for Distributed Systems and Networks (POLICY’03). Lake
Como, Italy: IEEE Computer Society, Jun. 2003, pp. 207–218.
http://www.cs.kent.ac.uk/pubs/2003/1636/content.pdf

P. F. Linington, Z. Milosevic, A. Tanaka and A. Vallecillo “Building
Enterprise Systems with ODP — An Introduction to Open Distributed
Processing.” Chapman & Hall/CRC Press, 2012.
http://theodpbook.lcc.uma.es/


Accountable objects:
Modeling Liability in Open
Distributed Systems
Antonio Vallecillo
Universidad de Málaga
Vienna, January 28, 2013
[Joint work with Peter F. Linington
and Hiroshi Miyazaki at ISO/IEC]

Accountable objects: Modeling Liability in Open Distributed Systems

Recommended

Recommended

More Related Content

Similar to Accountable objects: Modeling Liability in Open Distributed Systems

Similar to Accountable objects: Modeling Liability in Open Distributed Systems (20)

More from Antonio Vallecillo

More from Antonio Vallecillo (13)

Recently uploaded

Recently uploaded (20)

Accountable objects: Modeling Liability in Open Distributed Systems