Parliament work is regulated by a number of democratic rules about the way laws are proposed, discussed and nally voted. Despite a number variations, most parliaments share the same kind of workow supported by one or two assemblies. Such work ows are most of the time described by a regulation stated in natural language and generally approved by the assemblies themselves. This document is subject to some interpretation, especially by the administration responsible of the day to day management. Currently this management is also on-going strong electroni cation with even a direct exposure of the parliamentary work on the internet for better transparency and control by the citizen. In this paper we report about our work of modelling the parliamentary work ows, starting from the o cial documents and in-place systems. The aim of this work is multiple: rst, discover potential ambiguities and inconsistencies, then compare how similar are a number of parliaments and nally see how those models can be translated in the computer systems, especially in the perspective of the open-sourcing and mutualisation of such systems among di erent parliaments. Our practical experience of applying various modelling techniques is reported and discussed using two of the seven (!) parliaments running in Belgium. This comparison work relies both on a set of modelling requirements for such systems and on the SEQUAL reference framework for assessing the quality of models.
All democratic countries of the world run some kind of parliamentary system
whose main functions are to make law and control the work of the executive
power, following the principle of separation of powers. Parliaments may consist of
chambers or houses, and are usually either bicameral or unicameral. In bicameral
systems, the lower house is almost always the originator of legislation, while the
upper house is usually the body that o ers the "second look" and decides whether
to veto or approve the bills [
Law making also follows a general common process, starting from a bill either proposed by the executive or legislative body, then discussed by the assemblies. After preliminary readings, it is generally sent to specialised committees which will work on it. This will result in a number of amendments and nally a vote. In case of adoption, the law is then promulgated by being o cially signed by the authority (e.g the President or the King) and nally published. It is then generally followed by executive laws to enforce it. The following gure show this process for the Australian (bicameral) parliament.
With the raise of ICT, e-democracy is on its way and is present at various
levels: e-voting, e-forms, e-referendum... and among them e-legislation which is the
part we are interested in here. The electroni cation process has already started in
the 90's at the data and document level (scanning, OCR, meta-data, automated
generation of documents, di usion on web-site). More recently it is reaching the
legislative processes themselves. After initial phases of incertainty and
euphoria, this evolution is now reaching some maturity and being "institutionalised"
[
Most parliaments have now a strong ICT department in charge of this work. As parliaments have the same business, this also means that they need the same kind of solution. Rather than reinventing the wheel, some assemblies have started to collaborate and mutualise their e orts, this is especially true in Belgium which has a complex organisation with many assemblies at region, community and federal levels. This e ort also requires to be able to know precisely the commonalities and di erences between those assemblies and thus to model them precisely.
This paper reports about a practical case-study done in two regional
assemblies of Belgium in the context of mutualising their development with the
longer term goal to open-source the resulting more generic software [
This paper is structured as follows. In section 2, we will discuss about the requirements on the adequate language to capture parliamentary work ow. Then, in section 3, we will see how a number of candidate languages t those requirements by showing selected parts of our case studies. Section 4 will compare those models based both on the previous requirements and on a reference framework for assessing model quality. Based on this, a number of important lessons learned from those models will be discussed. Finally, section 5 will draw some conclusions and perspectives. 2
The main requirements discovered during the study were the following: { [BEHAV] Ability to capture behaviors. The language must be able to capture the dynamic nature of the parliamentary work ows. { [RESPO] Ability to capture responsibilities. The language should be able to describe the various agents playing some role in the system and their responsibilities. More precisely what they control and under which circumstances. { [GOAL] Ability to capture the goals. The language should be able to capture underlying goals of some operational construct. Goals can be either functional or non-functional (such as security, reliability, etc.) { [PRECISE] Precise language. The language should be precise and unambiguous. { [UNDER] Easy to understand. The language should be accessible to non specialist for validation purposes. Languages should preferably have a graphical semantics associated with it. { [TOOLS] Tool support. The language should be supported by tools at modelling level and at run-time level, either directly or through some model transformation. 3
This section reports about various modelling techniques used to model
parliamentary work. It does not claim to present all relevant techniques in an
exhaustive way. A useful reference for this is [
A use case is a description of a system's behaviour as it responds to a request that
originates from outside of that system. Use cases, stated simply, allow description
of sequences of events that, taken together, lead to a system doing something
useful.[
Notations for Use Case include UML Use Case (graphical) [
UML Use Cases diagrams have a good capacity to capture the context of
the system and the general responsibilities but lacks the capacity to re ect the
dynamic behavior. Textual templates can describe some part of the behavior
but not very precisely. Sequence diagrams used together enable a more precise
capture of behaviours but generally partial and at instance level. Goals can be
captured using methods like [
From [
Goal models enable to capture, structure and reason about system
properties and agent responsibilities. Languages like KAOS have precise semantics.
The goal level is de ned using temporal logics [
A nite state machine (FSM) is a model of behavior composed of a nite number
of states, transitions between those states, and actions. FSM have been extended
by Harel to statecharts to allow the modeling of superstates, concurrent states,
and activities as part of a state. This notation is now standardised in UML State
Diagrams [
State Diagrams are very popular. They are very easy to understand and thus to use to validate a behavior even with non-experts. The hierarchical structure allows also the system to be nicely described at progressive levels of details. There are precise semantics although several alternative semantics have been de ned, leaving possible ambiguities but generally for speci c cases. Goals can be associated with a FSM for example as invariant or obligation an FSM should enforce. This can be veri ed using model-checking tools.
FSM are also supported by tools for simulating the system or generating
the behavioral part of the code (e.g. Rhapsody [
Many notations have developed for modelling business processes, with di erent
coverages (activities, products, decisions, context), speci cation levels
(organisation, orchestration, web-services) and underlying semantics. To leverage this,
BPMN (Business Process Modelling Notation) is a current standardisation
effort aiming at unifying the expression of basic business process concepts (e.g.,
public and private processes, choreographies) as well as advanced modelling
concepts (e.g., exception handling, transaction compensation) [
UML - more software-oriented - also support this kind of modelling through the activity diagram which can represents business and operational step-by-step work ows of components in a system. Activity diagrams can be unstructured or organised using swimlanes (somehow similar to sequence diagram lifelines) which enable a better capture of the action responsibilities. Figure 6 shows a typical process model of the parliament work using those notations.
At semantic level, BPMN remains semi-formal although quite complete.
Some attempts have been made to more deeply formalise parts of it [
In this section, we will rst compare the qualities of the previous models w.r.t.
the requirements described in section 2. This discussion will also rely on the
SEQUAL reference framework for assessing the quality of models [
To consolidate this comparison, we used the SEQUAL reference framework
which de nes a number of model qualities: empirical, syntactical, semantical,
pragmatic, societal, knowledge and language [
State Diagrams Business
cess Models very good, hi- very good erarchical, scalable poor ProModel Empirical Semantical Pragmatic Knowledge
Use Cases Goal Trees State Diagrams Business Process Models Poor-to- medium-to- medium (di - good (control medium (de- good (depend- cult to struc- ow) pending on ing on re ne- ture) template used) ment checking
strategy) semi-formal formal (KAOS) formal (FSM) (petriformal nets) good good very good very good good (cap- very good (cap- poor good (business ture of sce- ture of system (states/transitionprocess level) nario/functions) goals) not directly linked to domain) medium medium good generic generic more speci c Organisational medium Language generic
The main lessons learned from those tables is that a single language does not t all our requirements. Activity diagrams seem the most adapted for our purpose given the current evolution of methods and tools while in the past, state machines were more the reference framework.
Other notations are useful to use in a complementary matter. Especially in the reengineering, and comparative study it is important to make sure the goals are fully aligned because variation in goals will inevitably result in variation at the work ow level and it is important to understand if some variation is a design decision or more fundamentally bound to a goal. 4.2
The use of modelling techniques helped greatly in the process of understanding the way the assemblies are working, their commonalities and di erences.
During the elicitation phase in the rst assembly (PCF), the various models were built from a number of sources of domain knowledge: the o cial regulation of each parliament, interviews with the sta and the documentation of the existing system. Building those models allowed us to have guidelines for completeness (e.g. asking about missing transitions) and for con ict identi cation (e.g. di erent actions reported by di erent sources). It allowed us to discover a number of undocumented choices left open by the regulation and to understand the rationale behind those choices. This resulted in an improvement of the documentation of the procedures, which are not only meant for developing a new system but also helpful as training material for new collaborators.
The work in the second assembly (PFB) did not start from scratch but was carried out based on the models from the rst assembly (PCF), assuming their would be only few di erences. This assumption was con rmed with the following main di erences: { Syntactic variations in the vocabulary used (e.g. the term for a law, for the board of presidents...) { Small behavioral di erences, typically variations in some transitions. Those are easily implemented at speci cation level and propagated to the implementation by regenerating the impacted code. { A more fundamental di erence is the distribution of roles: as PFB is smaller, the same people would typically handle a several tasks. As the model was built using roles, this has however no impact on our models. 4.3
Prior to our study, a strong model-based approach was already in place in PCF (based on nite state machines) and partially at PFB (based on a document management work ow).
The impact on the output quality was especially visible at PCF with a chain of model-based tools supporting the whole parliamentary process, from the gathering of minutes to the di usion of the reports on the website.
The traceability of the parliamentary process is also excellent based on the accumulation of state traces in the system. 4.4
The long term goal initiated by the case study is to eventually be able to share
common code between assemblies and even to open-source such code. The
current closed source model has a number of limits, especially when a number of
assemblies share common needs and have to develop their own solutions
separately and at high cost. This process has already started under the Tabellio
project [
For the process to be successful, the code quality should however be improved
prior to its open-sourcing and this is currently on-going. A major evolution is
the transition to a work ow management systems which is not based on code
generation as before but on a work ow engine, based on the Plone framework
and in coordination with other e-Government initiatives such as PloneGov [
In this paper, we explored various way to model parliamentary work ows using di erent languages. The comparison was driven by a real-world case study and performed using both speci c requirements and the SEQUAL reference framework. As expected, a single language cannot t all requirements and qualities. However business process models seem the most adapted for the needs of modelling parliamentary work ows. Other notations such as goal models allow the analyst to have a deeper insight of the system and to better understand variations between di erent assemblies and better manage the evolution of a given system.
Among the other lessons learned, the use of adequate models greatly helped in the understanding of the way each assembly was working and how similar they were. Models are also fundamental to deploy tool support. Firstly, in a modeldriven architecture perspective, models greatly ease the development of solutions by removing the need to write and test substantial part of the system. Secondly, in a mutualisation perspective, those tools can even be shared together with some representative models and guidelines on how to adapt them. The reuse is then maximal, reducing maintenance costs and allowing easy tuning to the need of other assemblies, especially those of developing countries. This also opens a number of interesting perspectives to further improve the way democracy works: speeding the process, introducing more transparency, etc.
At the methodological level, there is room for many improvements. The comparison work done here is very coarse grained. In order to draw more conclusions about the models and the way to use them, more precise metrics have to be dened and measured together with the reference quality framework. This work will be considered in the current re-engineering phase of the work ow system.
This work was nancially supported by the Walloon Region and European Union (ERDF and ESF). We also warmly thanks the sta of the respective parliaments.