Towards a Service-Oriented Architecture for eVoting
Boris Shishkov
1,2
and Marijn Janssen
3
1
Institute of Mathematics and Informatics, Bulgarian Academy of Sciences, Sofia, Bulgaria
2
IICREST, 53 Iv. Susanin Str., Sofia, Bulgaria
3
TBM – TU Delft, Jaffalaan 5, Delft, The Netherlands
b.b.shishkov@iicrest.org, M.F.W.H.A.Janssen@tudelft.nl
Keywords: eVoting, Conceptual Model, Requirements, Architecture.
Abstract: The latest advances in the Information and Communication Technology (ICT) are changing our society, but
have different implications on different domains. Some domains, such as the digital content –based
businesses, are enjoying (almost) full ICT utilization whereas other domains, assuming physical and/or
societal and/or “intuitive” inputs, are much less successful in terms of digitization. Voting using digital
technology (or “eVoting” for short) is in between those domains since: (i) the mere process of voting is a very
good “candidate” for digitization but at the same time (ii) the “surrounding” societal aspects are often difficult
to “frame” as Internet-based services. (i) can be seen from the “voting through computer” observed in several
European countries while (ii) can be seen from the lack (to date) of technology-enabled systems completely
supporting the voting process and its related aspects. Further, the conceptualization and implementation of
any voting system is to originate from legislation – this makes the goal of resolving (i) + (ii) even more
challenging. Hence, to benefit from ICT, the question remains what should be done and how it should be
done. The step from legislation to requirements and implementations taking into account socio-technical
aspects, is crucial for the successful realization of eVoting. Despite its relevance, this has been given hardly
sufficient attention in literature. This void is addressed by the current position paper; the contribution of the
paper is two-fold: we firstly propose a general technology-independent conceptual model on voting and on
this basis, we propose requirements for (partially) digitizing this process. Requirements are dependent on the
societal context and therefore we opted for focusing on one particular EU country where the transition to
eVoting is currently under discussion. We have planned as future research to reflect the identified
requirements into architectures and implementations, and to get experts’ feedback on this.
1 INTRODUCTION
Advances in the Information and Communication
Technology (ICT) are changing our society, and each
domain has its own “way” of utilizing computer /
Internet –based services. Some domains, such as the
digital content –based businesses, are enjoying
(almost) full ICT utilization. Other domains,
assuming physical and / or societal and / or “intuitive”
inputs, are less successful in terms of digitization.
Technology-enabled voting (referred to as “eVoting”
in the current paper) is in between those domains
since: (i) the mere process of voting is a very good
“candidate” for digitization but at the same time (ii)
the “surrounding” societal aspects are often difficult
to “frame” as Internet-based services. (i) can be seen
from the “voting through computer” observed in
several European countries while (ii) can be seen
from the lack (to date) of a technology-enabled
system completely supporting the voting process and
its related aspects (Scammell, 2016). Hence, the
eVoting domain should be conceptualized from a
socio-technical perspective. Further, the
conceptualization and implementation of any voting
system is to originate from legislation – this makes
the goal of resolving (i) + (ii) even more challenging.
Thus, the question remains what should be done and
how it should be done, in order to both benefit from
ICT advances and stay adequate in terms of societal
integrity. Meeting all requirements is crucial for e-
Voting, as failure in voting is not an option in a
democratic society. Still, the step from legislation to
requirements and implementations is essential for the
successful realization of eVoting. Nevertheless,
despite its relevance, this particular step has been
given hardly sufficient attention in literature. This
justifies our work, reported in the current position
paper – to conceptualize the voting process and derive
187
Shishkov B. and Janssen M.
Towards a Service-Oriented Architecture for eVoting.
DOI: 10.5220/0006223601870195
In Proceedings of the Sixth International Symposium on Business Modeling and Software Design (BMSD 2016), pages 187-195
ISBN: 978-989-758-190-8
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
requirements (and guidelines) for eVoting. Hence, the
contribution of the paper is two-fold: we firstly
propose a general technology-independent
conceptual model on voting (by “voting” we mean the
political voting for parliament, president, mayor, and
so on, taking place in different countries, as opposed
to for example corporate voting for board of directors
or other kinds of voting) and on this basis, we propose
requirements for (partially) digitizing this process.
Still, since those issues are inevitably based on a
particular societal context and because we need to be
“concrete” in our modeling activities, we have
decided to base our work on the situation in one
particular EU country where the transition to eVoting
is currently under discussion. We have planned as
future research to reflect the identified requirements
into architectures and implementations, and to get
experts’ feedback on this.
In the remaining of this paper: In Section 2 we
present theoretical background and in Section 3 we
present our research focus and propose a conceptual
model on voting accordingly. On this basis, we derive
requirements (Section 4). Then, in Section 5, we
discuss the next step, namely reflecting the identified
requirements in architectures and implementations,
and we propose some general guidelines in this
regard. Finally, we present the conclusions in Section
6.
2 THEORETICAL
BACKGROUND
We propose a technology-independent model on
voting, based on the theories of LAP – Enterprise
Ontology (Dietz, 2006), Organizational Semiotics
(Liu, 2000), Workflow Management (Van der Aalst,
2011), Service-Oriented Computing (Papazoglou,
2012), and Conceptual Modeling (Insfran et al.,
2002). Those are briefly outlined in the current
section.
2.1 LAP – Enterprise Ontology
The Language-Action Perspective (“LAP”) theory
(Shishkov et al., 2006) emphasizes the importance of
interaction and communication, recognizing that
language is not only used for exchanging information,
as in reports (for example), but that language is used
also to perform actions, as in promises or orders (for
example). Such actions are claimed to represent the
foundation of communities and organizations /
enterprises. This relates to the white-box model of an
organization that is of key importance for building
valid enterprise ontologies – this model
acknowledges actors (the entities fulfilling
corresponding actor-roles) who may be involved not
only in production acts (for example: deliver a pizza)
but also in coordination acts (for example: promise a
delivery), and those acts may be of relevance to three
perspectives of an organization, namely: documental
(documents being created and used, for example),
informational (customer enters PIN in order to realize
a bank transaction, for example), and essential (the
bank transaction itself, for example). Finally,
Enterprise Ontology considers a generic interaction
atomic pattern, claiming that any complex interaction
can be decomposed in such pattern primitives and
there are always two roles, namely customer (the one
who initiates anything, for example – order
something) and producer. There is a request-promise-
execute-state-accept actions sequence between them
and it can be reflected in a success layer and also a
failure layer, as well as discussion layer, in between.
For more information on Enterprise Ontology,
interested readers are referred to (Dietz, 2006).
2.2 Organizational Semiotics
Organizational Semiotics (OS) addresses a number of
concepts, such as sign and affordance, as essentially
useful in modeling a (real-life) system and adequately
considering relationships and meanings. Often what
we observe goes beyond the primary “appearance” –
for example, one could hold a Rolex pen not only as
a means of writing but also as a way of demonstrating
wealth (this is a sign). As for the affordance concept,
it relates to potential abilities (for example: a book
affords to be borrowed). Those concepts and also
other OS concepts, allow for building complex
models that reflect both semantics and norms (rules),
and that is reflected in the widely popular OS norm
pattern:
whenever <condition>
if <state>
then <agent>
is <deontic operator>
to <action>
The OS norm pattern is considered useful in modeling
relationships among entities, in the context of a
business process (Shishkov et al., 2006). For more
information on OS, interested readers are referred to
(Liu, 2000).
2.3 Workflow Management
It is claimed that any business process can be viewed
Sixth International Symposium on Business Modeling and Software Design
188
as a collection of processes, where a process can be
described as “a set of identifiable, repeatable actions
which are some way ordered and contribute to the
fulfilment of an objective”; typical process patterns
are sequence, parallelism, split, and so on.
Workflows play useful role in modeling business
processes and those models can be enriched in terms
of OS norms and / or entities information. For more
information on Workflow Management, interested
readers are referred to (Van der Aalst, 2011).
2.4 Service-Oriented Computing
Web services appear at high-level to be (dynamically)
composed by users, hiding thus their underlying
technical complexity – this complexity is with the
software components who are implementing the
corresponding service(s). Composability,
traceability, and interoperability are hence of crucial
importance in web service provisioning. More
information on those issues can be found in
(Papazoglou, 2012).
2.5 Conceptual Models
We consider a conceptual model as an abstraction
with regard to the real world. As for information (IT)
systems being developed, they inevitably need to be
based on such abstractions because among other
things, an information system is about the automation
of real life processes. Nevertheless, the value of
conceptual modeling efforts often remains unclear
(Insfran et al., 2002) and often software engineers do
not know whether a conceptual model represents the
user’s requirements. Finally, we argue that in order to
be useful in such a context, a conceptual model is to
adequately capture the real life functionalities that
would be (partially) automated, as part of the
development of information systems. In order to
address this and taking especially an eVoting
perspective, we:
a. would not keep the conceptual model too abstract
(we would have it reflect a particular (voting)
context);
b. would separate the technology-independent
conceptual modeling from the IT-inspired
requirements identification and specification;
c. would make particular assumptions in order to
“take out” of consideration aspects with no
relevance to what could actually depend on the IT
system as such.
We argue that this would lead to establishing a more
explicit role of conceptual modeling with regard to
the development of information systems (particularly
in the eVoting context) and also to guaranteeing that
conceptual modeling is aligned to requirements
engineering.
For this reason, we will firstly outline (in Section
3) the “modeling context”, namely the situation
(regarding eVoting) in one EU country (Sub-Section
3.1), secondly, we make our assumptions – in line
with what was mentioned above (Sub-Section 3.2),
thirdly, we propose a technology-independent model
(Sub-Section 3.3), and we extend this, by identifying
and specifying requirements (Section 4).
3 THE VOTING MODEL
As already mentioned, in this section, we consider the
societal context, we present assumptions, and in the
end – the technology-independent model on voting.
3.1 Societal Context
For the sake of “grounding” our research to a
particular societal context / case, we went for
considering a concrete eVoting context, namely the
situation in Bulgaria (Konstantinov et al., 2009). The
latest developments in Bulgaria with regard to
eVoting are considered “representative” because they
reflect the current EU visions on that issue, trying to
balance between the scepticism (observed in
Germany and other countries) and the “success
stories” (observed in Estonia and other countries).
Moreover, the current legislation changes and
initiatives in Bulgaria reflect the latest ICT
developments which was not the case in the countries
who have introduced eVoting several years ago. For
this reason, it is not surprising that eVoting dominated
an October’15 referendum in Bulgaria (Plevneliev,
2016); then the majority of Bulgarians voted in
support of “IT-enabled voting” and the “pro”
campaign was backed by particular stated eVoting
public demands that may (eventually) be reflected in
corresponding legislation changes; some of those
demands are presented and briefly discussed below:
secrecy of vote, possibly achieved through
anonymous credentials, such that not even the
system "knows" how a person has voted;
cost adequacy, possibly achieved through smart
decisions rather than posh hardware that would
generate future “dependencies”;
guarantee against violations with regard to the
way the system works;
guarantee against manipulations of the final
Towards a Service-Oriented Architecture for eVoting
189
voting results;
support of secure communication between the
computers and the servers that is to be possibly
cryptography-enriched.
controllability - any third parties should be able to
"verify" that the system is working properly;
guarantee that each vote has been counted and that
the person who had voted would not be allowed to
vote again;
fault-reaction is to be established as guarantee
that even if the system (partially) crashes, it would
recover and this would not affect its storage and
processing functions;
ease of use even by persons who are not of high
computer literacy;
no need for extra qualification of the election
authorities.
Obviously, such a public demands list cannot be
exhaustive and it is also inevitably unstructured.
Moreover, those “demands” reflect a mixture of
things – from FUNCTIONAL to NON-
FUNCTIONAL, from CONCEPTUAL to
TECHNICAL, and so on. For this reason, we should
“extract” some information in support of our
technology-independent functional conceptual
model, and we should as well extract information in
support of the requirements' identification to be
addressed in Section 4. Hence, in the following list,
we refine the demands, to achieve input for our
conceptual model, abstracting from all non-functional
and technical aspects:
secrecy of vote;
fair reflection of votes;
fair communication of inter-
mediary results;
fair counting of votes;
the voting – easy for all having
rights to vote.
Thus, in line with those demands, any person with
voting rights in Bulgaria should be able to vote. This
assumes that no special qualification / skills are
needed, in such a way that both his/her vote is fairly
reflected in the voting system and the secrecy of his /
her vote is guaranteed (this means that the vote should
be counted but it should not be linked in any way to
the person who has executed the voting). Finally, it
should be guaranteed that all intermediary results are
properly communicated to the voting “central” and in
the end – all votes are correctly counted, to guarantee
adequate political representativeness.
In Bulgaria, people vote for parliament, for presi-
dent, for local authorities, and also in referenda.
Voting is preceded by a campaign. During the
campaign, candidates / parties have the right to
register for the vote and also to campaign for /
promote their ideas. This is supposed to stimulate
people to analyse the current situation and the
(potential) impact of different political influences.
Then, the campaign stops and the day before the
elections is made free of campaigning – to avoid
pressure on voting in a certain direction. This is
followed by the voting “day” lasting 12 hours; during
this 12-hour period, people have the right to go and
vote (or not to do so), and once voting is done, it is
done – it is impossible to return back to the voting
station and claim changing mind and voting again.
Further, when the voting “day” is over, votes are
counted in each voting station and this would
generate the so called “raw” results, reflected in a list
of candidates and corresponding numbers. Finally, all
such lists are “brought together” as the source for
calculating the overall results per country and / or per
town and / or per county, and so on.
3.2 Assumptions
The above is the starting point for developing our
conceptual model. For this reason, we should know
what to keep “in” and what to leave “out”, and this
decision is inevitably technology-driven because we
leave out things that cannot be (at all) dependent on
what the technology can offer. For example, if Steve
is going to vote from home via computer and his
father is standing behind him, influencing his vote,
then we cannot do anything about this no matter how
advanced technology is – this is just matter of each
person’s observing and upholding the rights each of
us has. We thus make several assumptions: (i)
issues of societal relevance which
are nonetheless beyond the infor-
mation system control are outside
the scope of this research (consider the
above example of Steve’s voting). (ii) We assume
sufficient IT literacy among the
population, realizing nevertheless that there are
poorly developed regions where this is not yet the
case. (iii) We assume a democratic country in which
governments do not manipulate the
election process. The above assumptions
maybe (partially) IT-inspired but even so, the
assumptions have straightforward impact with regard
to the technology-independent conceptual model
because they lead us to what to leave out of the model.
Sixth International Symposium on Business Modeling and Software Design
190
3.3 The Voting Model
In order to keep (as promised) the model abstract
(thus simple) but also properly focused, we: (i) apply
only two concepts, namely actor-role and
relationship; (ii) take into account what was
presented in Sub-Section 3.1 and Sub-Section 3.2.
Our Actor-Role (AR) concept is consistent with
Enterprise Ontology (see Section 2), suggesting that
‘actor’ is the (human) entity executing a particular
task while ‘actor-role’ is about specifying the task
itself, abstracting from who exactly is fulfilling this.
For example, if a Professor is sending fax, then (s)he
is doing something that is part of what the Secretary
normally does and for this reason, determining the
‘actor-role’ here points to the label ‘SECRETARY’
(not ‘PROFESSOR’). Our Relationship (R) concept
is consistent with the SDBC approach (Shishkov,
2005) and is about whether or not collaboration is
needed between two ARs that is necessary for one or
both of them to deliver what they have to deliver.
Hence, we have identified the following ARs in
the context of what was presented in this section:
AR1 –
CAMPAIGNER: the one(s) campaigning in
favour of a particular policy / party / vision and
influencing the people in that way;
AR2 –
VOTER: the one(s) voting for parliament /
president / … and thus executing basic rights in the
country;
AR3 –
PRIMARY COUNTER: the one(s)
counting the votes in a particular voting station;
AR4 –
SECONDARY COUNTER: the one(s)
aggregating the final result, by putting together the
voting results from the voting stations;
AR5 –
ORGANIZER: the one(s) organizing the
voting process and supporting all above-mentioned
accordingly;
AR6 –
CONTROLLER: the one(s) controlling all
above-mentioned;
7 –
SYSTEM: even though this is not an actor-
role, we have to somehow model abstractly the “place
holder” where all voting “goes”.
Further, we have identified the following Rs:
AR1-AR2 suggesting that the CAMPAIGNER is
promoting political messages that are supposed to
influence the VOTER;
AR2-SYSTEM suggesting that the VOTER
provides essential input to the SYSTEM, namely the
vote;
SYSTEM-AR3 suggesting that the SYSTEM has
impact with regard to each voting station (said
otherwise, each voting station has its “own”
SYSTEM), by providing the information needed by
the PRIMARY COUNTER for calculating the station
results;
AR3-AR4 suggesting that the SECONDARY
COUNTER needs the PRIMARY CONTER’s
feedback from each voting station, in order to
aggregate the overall voting results;
AR5-ALL suggesting the ORGANIZER of the
elections has relationship with all above-mentioned
ARs and the SYSTEM as follows: creating conditions
for the CAMPAIGNER to do promotion adequately;
establishing that the rights of the VOTER are
guaranteed; establishing rules and mechanisms
according to which the PRIMARY COUNTER and
the SECONDARY COUNTER should fulfil their
corresponding tasks; establishing and running the
voting SYSTEM;
A6-ALL suggesting that the CONTROLLER
should execute effective control concerning all
above-mentioned ARs and the SYSTEM, as guarantee
that the voting is fair.
This is the basis for our conceptual model and as
mentioned before, we abstract from several issues (as
according to Sub-Section 3.2) and an example of this
is that we do not consider an AR pointing to the one(s)
(outside the CAMPAIGNER) who may be somehow
influencing the decision of the VOTER – this could
have been modeled as an AR by itself but we have not
done this because of the lack of technical relevance,
as explained above.
We present our conceptual model on Figure 1 and
we use simple and intuitive graphical notations: the
labels of the ARs are put inside boxes and the
SYSTEM is presented as oval, while the Rs are
represented as lines (the arrows indicate who is
ADDRESSED in the relationship – for example: if
the CAMPAIGNER is influencing the VOTER, then
the arrow should be at the VOTER end because the
VOTER is addressed by this).
S Y S T E M
CAMPAIGNER
V
OTER
PRIMARY COUNTER
SECONDARY COUNTER
ORGANIZER
CONTROLLER
influence
feed (by votin
g
)
enable
control
provide feedback
feed (by votin
g
output)
Figure 1: The Voting Conceptual Model.
As seen on the figure, we have not only drawn
arrows at each line (lines representing Rs) but we
Towards a Service-Oriented Architecture for eVoting
191
have also added labels there: the CAMPAIGNER
would influence the VOTER, the ORGANIZER
would enable the SYSTEM, and so on.
We claim that such an essential conceptual model
is a good basis for further elaborations in different
directions, such as structure (where we model entities
and their relations), behaviour (where we model all
activities in sequence, parallelism, and so on), data,
and so on. The model would stay as “guarantee” for
the inter-model consistency among structural,
behavioural, data, and other “sub”-models. For the
sake of brevity, we are not going in more details in
presenting and discussing those issues. Still, the
SDBC approach provides useful insight in this
direction (Shishkov, 2005).
In line with the goals of the current paper, as
mentioned in the Introduction, we go for extending
the conceptual model, by identifying (technology-
inspired) requirements, as part of the effort of
supporting the development of eVoting systems. This
will be addressed in the next section.
4 eVOTING REQUIREMENTS
In the current section, we will firstly elaborate the
public demands (see Sub-Section 3.1) and then we
will introduce our way of modeling requirements,
being certainly restricted by the conceptual model
(see Sub-Section 3.3).
4.1 Public Demands' Elaboration
In the current sub-section, we elaborate the
previously listed public demands towards eVoting,
taking into account that all those issues concern the
people and the technology (what the current
technological possibilities are), and the legislation.
The current demands’ elaboration would be useful as
basis for our reflecting the demands in corresponding
technical requirements.
With regard to the SECRECY OF VOTE demand,
there are two things: (i) it is to be guaranteed that
nobody can know how a person has
voted; (ii) it is to be ensured that the person has been
marked as “voted”, such that (s)he would not go
to vote again.
With regard to the COST ADEQUACY demand,
the only way of avoiding the “big expensive black
box” is to conceptualize the eVoting process such that
it is known what technology is
needed for what.
A way to guarantee against VIOLATIONS with
regard to the way the System is working, is to present
the user with a simple and exhaustive
list of options, with no possibilities to do
anything outside the presented options.
A way to guarantee agains MANIPULATIONS
OF THE FINAL RESULTS is to keep things at two
levels, such that the Primary Counters
generate the “raw” results based on
which the Secondary Counters generate
the final results and this all stays stored with
possibility to check in the future.
The COMPUTER-SERVER communication is to
be such that there is guarantee that a “packet”
sent by a computer is received by
the server and by noone else; this is a
matter of organization and also a matter of
networking protocols.
CONTROLLABILITY can be partially achieved
if all intermediary results get
transparent and then the only remaining
challenge is how are the “raw” results generated.
FAULT REACTION is a matter of
recoverability and this is a non-fuctional
concern that has to be addressed from a functional
perspective nevertheless.
EASE OF USE is a matter of design.
The issue on QUALIFICATIONS needed for
being involved in eVoting is a matter of legislation;
as it was mentioned before, sufficient IT literacy
among the population is assumed.
4.2 Way of Modeling Requirements
We consider OS norms (see Sub-Section 2.2) as
helpful in the process of specifying requirements in
this context not only because Organizational
Semiotics is well-known for its strengths with regard
to capturing societal aspects but also because OS
norms have been researched also as useful with
regard to requirements identification and
specification. In particular, it has been studied how
OS norms can help deriving use cases from business
processes (Shishkov, 2005).
OS norms determine the conditions and constrains
in controlling optional and conditional actions. They
govern the behaviour of actors (agents), normally to
decide when certain actions are performed. OS norms
define clearly the roles, functions, responsibilities and
authorities of the actors, for example:
whenever John is Customer of VISA
if VISA increase John’s credit card limit
then John
is allowed
to use more credit.
Sixth International Symposium on Business Modeling and Software Design
192
4.3 The eVoting Requirements
Starting from unstructured information – the public
demands presented in Sub-Section 3.1 (a mixture of
technology-independent and technical issues), we had
to firstly capture the functional gist (the conceptual
model), abstracting from technical details – see
Figure 1. Only on this basis, it was possible to
adequately elaborate the public demands (see Sub-
Section 4.1), making sure that each (technical) detail
properly fits in the “big picture”.
person is
asking to vote
person is voting
votin
g
ri
g
hts?
person is marked
“voted”
vote counted,
person not associated
y
es
no
Figure 2: Workflow Pattern Corresponding to OS Norm 1.
Hence, inspired by Organizational Semiotics, we
can now specify eVoting requirements, by means of
OS norms, and in order to achieve better visualization
and possible good basis for simulation (it this may be
needed), we also reflect the OS norms in workflow,
as studied by Shishkov (2005). Further, the demands
being considered are many while the scope of the
current paper is limited; hence, for the sake of brevity,
we take only several of them (planning the rest as
future work) and reflect them in the specification of
requirements and in the next section, we briefly
discuss the next step: “requirements-to-architecture”.
We take in this section several eVoting public
demands and we reflect them in specified
requirements expressed in terms of OS norms. We
start from the SECRECY OF VOTE one:
OS Norm 1:
Whenever John has voting rights
if John is executing eVoting
then the eVoting system
is (i) obliged to mark John as “voted”
is (ii) prohibited from recording the way
John has voted.
Based on OS Norm 1, we derive a workflow pattern
expressed with the notations of UML Activity
Diagram (UML, 2016) – see Fig. 2.
With regard to the VIOLATION public demand,
we formulate the following norm:
OS Norm 2:
whenever John is executing eVoting
if John is attempting a not allowed action
then the eVoting system
is prohibited from taking any action.
Based on OS Norm 2, we derive a workflow pattern
– see Fig. 3.
person is attempting
an action
action allowed?
action is performed
action is blocked
y
es no
Figure 3: Workflow Pattern Corresponding to OS Norm 2.
5 TOWARDS A
SERVICE-ORIENTED
ARCHITECTURE
With regard to the “requirements-to-architecture”
step, we consider the SDBC Approach (Shishkov,
2005) allowing for a component-based alignment
between enterprise modeling and software design,
ending up in specified software components that fit in
the architecture. Those components we relate to web
services in a way that what we see as web service
“manifestation” is the functionality delivered by
corresponding underlying software component(s).
Further, we realize that in currently dealing with
distributed cloud applications, it would often be that
different software components have different origin
thus not belonging to the same software application.
Still, the SDBC Architecture is that needed
abstraction which establishes and keeps the overall
system “logic” no matter if a particular task is realized
by the software application –to-be or by
(dynamically) composed web services. Further
detailing is left for future research. What we present
in the current section is the SDBC-orientation we take
with regard to architecture, noting the useful relation
Towards a Service-Oriented Architecture for eVoting
193
to web services. For this reason, we briefly present
below the SDBC Approach, SDBC standing for:
Software Derived from Business
Components’.
Firstly, SDBC assumes 4 modeling perspectives,
namely: Structural Perspective that reflects entities
and their relationships; Dynamic Perspective that
reflects the overall business process and
corresponding to this – the states of each entity,
evolving accordingly; Data Perspective that reflects
the information flows across entities and within the
business process; Language-Action Perspective that
reflects real-life human communication and
expression of promises, commitments, etc. as also
relevant to soundly building an exhaustive enterprise
model.
Secondly, among SDBC’s underlying theories are
Enterprise Ontology and Organizational Semiotics
(Shishkov et al., 2006) - see Section 2, which makes
the approach siutable especially in the eVoting
context of the current paper.
Thirdly, among the main SDBC concepts are the
following:
Component vs CoMponent: while components
represent part of the whole, coMponents reflect a
model of a component adequately elaborated in all
4 perspectives (see above), and we could thus
have business components (business sub-systems)
and software components (pieces of implemented
software) as well as business coMponents and
software coMponents, respectively;
General vs Generic: those concepts are both
about re-use, still – general is about re-using an
abstract core (a general reservation engine, for
example) while generic is about parameterizing
something that is multi-specific (a car system to
be adjusted to automatic or gear regime, for
example);
Software Specification Model – this is
a technology-independent functionality model of
the software system-to-be.
To summarize the SDBC outline, we use Fig. 4:
Abbreviations:
bc – Business Component ssm – Software specification model
bk – Business CoMponent sc – Software Component
glbk – General Business CoMponent sk – Software CoMponent
gcbk – Generic Business CoMponent
Figure 4: SDBC – Outline (Shishkov, 2005).
As seen from the figure, we consider a Business
System from which a Business Component(s) is to be
identified and then reflected in a relevant model – a
Business CoMponent. Another way for arriving at a
Business CoMponent is by applying re-use: either
extending a general Business CoMponent or
parameterizing a generic one. Then, the Business
CoMponent should be elaborated with the domain-
imposed requirements, in order to add
elicitation on the particular context in which its
corresponding Business Component exists within the
Business System. Then, a mapping towards a
software specification model should take place and
the user-defined requirements are to be
considered, since the derived software model should
reflect not only the original business features but also
the particular requirements towards the software
system-to-be. The software specification model in
turn needs a precise elaboration so that it provides
sufficient elicitation in terms of structure, dynamics,
data and language-action –related aspects. It needs
also to be decomposed into a number of Software
CoMponents reflecting functionality pieces. Those
CoMponents then are to undergo realization and
implementation, being reflected in this way in a set of
Software Components. Some Software Components
could also be purchased. The Software Components
are implemented using Software Component
technologies, such as .NET or EJB, for instance.
Finally, the (resulting) component-based ICT
application would support informationally the target
Business System, by automating anything that
Sixth International Symposium on Business Modeling and Software Design
194
concerns the considered Business Component
(identified from the mentioned system).
SDBC was just briefly introduced above. Still,
interested readers can find more information on
SDBC in (Shishkov, 2005).
As mentioned in the previous section, we just
briefly discuss our views on the “requirements-to-
architecture” step in the eVoting context, and we
leave it for future research to go in depth in this
direction, possibly adapting some SDBC features
accordingly, and of course validating our results by
means of case studies. Still, it becomes clear how we
proceed from requirements to
architecture and how we consider service-
orientation.
6 CONCLUSIONS
Understanding eVoting systems requires
understanding the legislative and societal context. In
this position paper we presented guidelines to come
from global to detailed requirements, and then – to
(service-oriented) architecture, based on Enterprise
Ontology, Organizational Semiotics, and the SDBC
Approach. The essence is that multiple theories need
to be employed to understand and elicit requirements.
Formal modeling should ensure that the requirements
are consistent and meet the societal expectations.
REFERENCES
Dietz, J.L.G., 2006. Enterprise Ontology, Theory and
Methodology. Springer-Verlag, Berlin Heidelberg.
Insfran, E., Pastor, O., Wieringa, R., 2002. Requirements
Engineering-Based Conceptual Modelling. In
Requirements Engineering journal, Vol. 7, Nr. 2, 2002.
Springer-Verlag.
Konstantinov, M., Pelova, G., Boneva, J., 2009.
Mathematics of the Bulgarian Electoral System. In
AMEE’09, 35th International Conference on
Applications of Mathematics in Engineering and
Economics. AIP.
Liu, K., 2000. Semiotics in Information Systems
Engineering. Cambridge University Press, Cambridge.
Papazoglou, M., 2012. Web Services and SOA: Principles
and Technology, Prentice Hall, 2
nd
edition.
Plevneliev, R., 2016. Statement by President Rosen
Plevneliev at His 4th Annual Press Conference,
Published on the website of the President of the
Republic of Bulgaria: http://www.president.bg.
Scammell, R., 2016. Internet Voting a Success in Two
European Countries, Published on the European
University Institute website: http://www.eui.eu.
Shishkov, B., 2005. Software Specification Based on Re-
usable Business Components (PhD Thesis), TU Delft –
SIKS Publishing. Delft.
Shishkov, B., Dietz, J.L.G., Liu, K., 2006. Bridging the
Language-Action Perspective and Organizational
Semiotics in SDBC. In ICEIS’06, 8th International
Conference on Enterprise Information Systems.
SCITEPRESS.
UML, 2016, the website on the Unified Modeling
Language: http://www.uml.org.
Van der Aalst, W., 2011. Process Mining - Discovery,
Conformance and Enhancement of Business Processes.
Springer-Verlag, Berlin Heidelberg.
Towards a Service-Oriented Architecture for eVoting
195