A fundamental privacy principle, which is enforced in many privacy-enhancing technologies, is data minimization, i.e. the amount of personal data that are revealed to others and extend to which they are processed should be minimized. Privacy-enhancing identity management is important for processing personal data, the purpose of which is to protect personal data. This is especially relevant for communication via Internet where users are leaving much personal data. Privacy issues should be embedded into a system's core functionality. Minimization of data should be maintained and controlled throughout the systems lifecycle, from the early stages of system analysis and design to implementation. The primary goal of this paper is to present a conceptual modelling method, including the framework, modelling process and the basic modelling constructs, which enables minimization of data. Data cannot be analysed separately without taken into account the processes that cause the changes of data as well as goals. Analysis of relevant data contributes to the problem of data minimization in privacy-enhancing technologies.
Privacy is an essential and fundamental human right
Nowadays business more and more takes place on the Internet. This situation increases problems to secure personal data. The processing of the personal data is usually not transparent for the users, but it can have painful consequences to privacy and security of the users. Sophisticated technologies provide possibilities to trace, store and use non-protected data for different purposes. The question is what data and how much data should be collected, stored and shared doing business online. The answer could be found in data analysis and design methods, which could help to analyse and minimize the amount of personal data that are revealed to others. The problem today is that the methods are not pragmaticdriven and they have not enough semantic power for analysis of data.
Privacy-enhancing identity management (IDM) systems are designed to
enforce legal privacy requirements to guarantee the processing of privacy
compliant data
Data is an important asset concerning information privacy. Privacy-enhancing identity management systems require accurate data analysis for processing personal data. Data is created, processed and consumed in various transactions for different operational and analytical purposes. As data is the main element for the management of information privacy, it is critical to identify a minimal amount of data, which are relevant in the specific context or scenario. Interdependencies among models that represent different aspects of the system cannot be analysed in isolation. Business data and business processes should be analysed together. Just having an integrated and systematic modelling method provides possibility to analyse structural, interactive and behavioural aspects of a system together. Such method can be applied for the analysis of different scenarios including such non-functional requirements as information privacy issues. The main goal of this paper is to present a framework of a service-oriented modelling method and a modelling process that could be applied for data analysis and design to solve data minimisation problems.
Model Driven Architecture (MDA)
Pragmatic specifications aim to provide motivation for conceptual representations of enterprise components at the semantic level that defines business processes across organisational and technical system boundaries. Pragmatic knowledge, expressed in terms of pragmatic entities such as goals, problems and opportunities, provides motivation for conceptual representations of enterprise components, which take part in various business processes of an enterprise. To structure the pragmatic knowledge about business processes (as services) is important, because such knowledge provides motivation for various configurations of service architectures and defines the ‘why’ aspect of the problem domain. Pragmatic specifications are necessary for several reasons. They motivate service events and show the guidelines over how pragmatic aspects are mapped to conceptual representations, which define the semantics of business design, including the structural, behavioural and interactive aspects of business processes.
Pragmatic dependencies can be viewed as modelling basis to reason about the
intentions of designers related to new solutions. Pragmatic entities such as goals,
problems, and opportunities can be related by pragmatic dependencies and
analysed in different situations. Any business process functionality can be defined
as a service. A service, in different contexts, from pragmatic point of view can
be regarded as different pragmatic entities such as a problem, opportunity or a
goal. Business activities can be defined in terms of a set of interaction loops
between service requester and a service provider, and linked to design goals
Pragmatic specifications aim to provide justification for conceptual
representations of data and processes. To understand how and why technical system
components are useful and how they fit into the overall organizational system at least
three modelling levels of information system specifications are necessary:
pragmatic level, semantic level and syntactic level
Legend: PRAGMATIC LEVEL SEMANTIC LEVEL SYNTACTIC LEVEL motivation traceability Business-Oriented
Analysis Service-Oriented
Analysis
TechnologyOriented Design
Computation Neutral Modelling
(CNM)
Implementation Specific Modelling (ISM)
Pragmatic level is the level where business-oriented analysis is done. Analysis
at this level using pragmatic dependencies
The fitness of system specifications between these levels is critical for the
success of the final result. Consistency between levels much depends on having
appropriate modelling techniques for the refinement of pragmatic entities that
justify and represent their structural and dynamic aspects at the semantic level.
An integrated modelling way provides possibility to check consistency between
levels. It also underlines the possibilities for requirements traceability, which is
crucial for verification and validation of system requirements
Service-oriented modelling method for information system design
The definition of service presented in this method explains the necessary
elements and provides with the guidelines how these elements are related to form
service architecture. There are two ontological perspectives of communication
action
The intersubjective perspective defines how actors (service requesters and
service providers) are related to each other. This perspective is important as it
presents the actors, as independent loosely coupled components, who add value by
performing some activities. It signifies certain commitment and responsibilities
between enterprise actors
The objective perspective defines how different objects change when the actions during interaction process take place. The objective perspective can be applied to represent the internal behaviour of the objects. It represents data, which is analysed in the context of interaction between organizational and technical system components. Interactions among different actors can be used to manifest object property changes that are results of different actions. Property changes are important for eliciting of semantic meaning of the problem domain. The cohesion of these two perspectives results into a single modelling notation (construct), which allows the integration of static and dynamic aspects of the system, which are important to maintain a holistic representation where external and internal views of service conceptualizations are visualized together.
A starting point of the ontological definition of an enterprise system in the presented service-oriented foundation is quite similar to ontological understanding of system and enterprise as a system. Enterprise system is a composition of the organizational and technical components, which are viewed as various types of enterprise actors and which interact as service requesters and service providers. Actors are subsystems that are represented by individuals, organizations and their divisions or roles, which denote groups of people. Technical actors are subsystems such as machines, software and hardware components, etc. Any two actors can be linked by inheritance, composition, classification or interaction dependencies, which are represented graphically in figure 2.
Inheritance Composition Classification
Interaction
Inheritance dependency between actors is used for sharing the static and dynamic similarities. More specific actors inherit the composition and interaction dependencies from more general actors. Dependencies represent additional intrinsic actor interoperation features and structural properties that are prescribed by an enterprise system. Composition is a conceptual dependency used to relate a whole to other concepts that are viewed as parts. It is a stricter semantic relation as compared to an aggregation and a composition that is defined in the objectoriented approaches.
Classification link between two actors is used to define their instances. In conceptual modelling, an instance can be viewed as an element of a set that is defined by a concept it belongs to. In the same way as an object can be manipulated by operations, an actor has interaction privileges and responsibilities that are defined by the interaction dependencies.
Interaction dependencies are used to conceptualize services between various enterprise system actors. Since actors are implemented as organizational and technical system components, they can use each other according to prescribed patterns to achieve their goals. Two interaction dependencies into opposite directions between a service requester and service provider define a typical action workflow loop. Interaction flows of a conference management system are represented in figure 3.
Author Fig. 3. Example of semantic dependencies between actors
Identification of interaction flows and static dependencies among actors is the first step in the modelling process. An interaction link between two actors indicates that one actor depends on another actor by a specific action. It represents an intersubjective perspective of interaction. For instance, a contact person submits a paper to the conference. He wants this paper to be published. It can be done by accept action, which is initiated by the PC chair. The conference has quite different goals. For instance, conference goals would be to make the submission and reviewing processes as smooth as possible and to be the best conference, i.e. to accept just the best papers.
There are two actors involved in this business process, a contact person who will submit a paper and a conference. A conference is composed of PC Chairs and Reviewers. A conference management system has delegated all major communication through a PC chair, which is a part of a Conference (see composition dependency). PC Chair has a goal to handle reviewing process as good as possible that is to do everything in time. He appoints reviewers and sends the review results to a contact person. The task of reviewers is to reviews the papers. A contact person who is also an author (see inheritance dependency) submits the paper to the conference, by triggering the action Submit. When the person submits the paper, the conference has two possibilities the paper will be accepted, or rejected (see actions Accept and Reject). A Contact Person has also possibility to withdraw the paper (see action Withdraw). When the conference receives the submitted paper, a PC Chair chooses reviewers and sends the paper for review. After reviewing process, a Reviewer returns review to PC Chair (see action Return Review). The results of the review will be sent to contact person (acceptance information or rejection). 4
The main contribution of this paper is to present the modelling process that consists of five fundamental steps, which support the incremental and systematic service-oriented analysis and design process. An integrated modelling process provides the guidelines for the transition between levels (see figure 1). The requirements traceability is critical for change management, verification and validation processes. A starting point of service-oriented analysis is identification of actor goals and interaction dependencies among service requesters and service providers. The structural aspects of a system are used to represent business data. The behavioural aspects are clarified by defining object transition effects. Without ability to represent noteworthy structural changes, it would be difficult to understand the deep semantics of interactions. Having possibility to reiterate these modelling steps, helps to keep data minimal. The steps of this process are as follows: 1. Identification of the main scenario.
Suppose the conference needs to accept just the best papers and a contact
person hopes that his paper to be among those accepted papers. This scenario
represents a normal flow of events
The second interaction loop deals with the actions of appointing reviewers and retuning reviews. It is as follows: if Appoint Reviewers(PC Chair Reviewer) then Return Review(Reviewer PC Chair).
The interaction flows among actors are graphically illustrated in figure 4.
Contact Person
Interaction flows are the special types of concepts that represent moving flows. In service-oriented modelling method, solid rectangles are used for the denotation of material flows and light boxes show information flows. An action with a missing data or material flow is understood as a decision or control flow. Actions are performed by actors and are represented by ellipses. They are necessary for transferring flows between subsystems, which are represented by various organizational components. Actors are denoted by square rectangles.
2. Definition of actions in terms of transition dependencies.
The internal effects of objects can be expressed by using transition links (──)
between various classes of objects. There are three fundamental ways for
representing object behaviour by using reclassification, creation and termination
actions
3. Identification of a noteworthy semantic difference in every action. This step is important for identification of attributes, which are affected during object transitions from the pre-condition to post-condition classes. The semantic difference must be defined for every transition dependency by using mandatory attribute links. Various types of attribute dependencies in a conference management system are represented in figure 6. For example, the Accept action changes the state of a Paper object from Reviewed to Accepted. Note that each Paper[Accepted] must be characterized by five properties (Presentation Time, Review, List of Authors, Submission number, Contact Person) and Paper[Reviewed] - by four properties. The noteworthy semantic difference is represented by the complementary attribute Presentation Time.
4. Refactoring.
It is difficult to get initial diagram without inconsistencies and redundancies from the start. Classes and their attributes must be revisited and their semantics examined several times. The refactoring step is necessary to keep conceptual models clean from inconsistent attributes as well as minimize diagrams as much as possible. The refactoring process (Fowler, 1999) does not alter semantics of specification. Refactoring is an essential characteristic of good engineering, because it makes necessary structural changes in order to make modelling clean and understandable. The diagram, which illustrates the outcome of this step, is presented in figure 6.
Submission
Inheritance mechanism allows sharing attributes via generalization/specialization relations. So, inheritance hierarchies can be used to reduce the diagram. For instance, Accepted Paper class in this diagram inherits attributes from Paper in state Reviewed.
5. Describing the alternative scenario.
This step is important, because the modelling process should provide with the possibility to demonstrate available alternatives to the main course of events. Note that the Reject event is an alternative to Accept. Therefore, it should be added at this step (see figure 3).
We have introduced an incremental way of modelling enforcing only minimal data sets, which are represented for various types of actions. Five steps of analysis process are also important for integrity control between static and dynamic aspects in a system. The data necessary in this business process are limited just to most relevant, adequate and not excessive. But the process of data minimisation alone will not solve the problem. Creation of personal data records must be adequate with respect to basic activities in a transaction. It means that analysis of data should be done taking into account the context of business process as well as data handling policy that the service requester and service provider establish in an agreement. How to find out which data are relevant to specific business process depends much not only on structural analysis, but on interactions and behavioural aspects of a system.
Data life cycles vary in different scenarios. Data life cycle analysis is important to understand and to justify why and when personal data can be stored in the system and when it should be deleted. Creation of personal data records and keeping them in identifiable form not longer than necessary is important principle of privacy enhancement technologies. To manage data life cycle implies analysis of different aspects of data, what data is processed, by whom, why, where, and how. To get answers to all these questions a holistic integrated representation of a system should be analysed. 5
Problems in the area of personal data processing such as lack of data minimization and data life cycle management require the new research solutions. Privacy issues are always embedded into some organization and are related to business scenarios. It means that these scenarios should be analysed and designed together with functional requirements. As data is the main element concerning the management of information privacy, it is critical to have a way of data analysis for the specific context of business scenario. The advantage of this conceptual modelling method is that it facilitates reasoning about semantic integrity of data. It provides a modelling process and modelling techniques for early requirements analysis, where pragmatic and semantic aspects of different scenarios can be analysed together.
The modelling process supports the traceability between different levels of architectural framework, which is critical for understanding how and why technical system components are useful and how they fit into overall organizational system. Analysis using this method can be applied to solve the problems of data minimization. Applying a method for analysis and design of privacy concerns would contribute with a new knowledge in designing security assurance and privacy-enhancing mechanisms. The method could be applied for diagnosing the redundant data, i.e. to distinguish between object properties, which are relevant or not justified with respect to scenarios in the secondary interaction loops. It can be also used to detect the temporal data or to distinguish between object properties that can be accessible not longer than necessary. The method is able to justify the persistent data, which must be to retained in relation to data transfer scenarios and policies, if various commitments are broken.