españa (master thesis 2008) a generic model of information systems

A GENERIC MODEL OF INFORMATION SYSTEMS

THEORY AND PRACTICE

Sergio España Cubillo

Master Thesis – Postgraduate studies 2007/2008 “Máster en Ingeniería del Software, Métodos Formales

y Sistemas de Información”

Directed by PhD Óscar Pastor López

A generic model of Information Systems Master thesis of Sergio España

2

3

A GENERIC MODEL OF INFORMATION SYSTEMS

THEORY AND PRACTICE

Sergio España Cubillo

Master Thesis – Postgraduate studies 2007/2008 “Máster en Ingeniería del Software, Métodos Formales y

Sistemas de Información”

Directed by PhD Óscar Pastor López

Abstract This work defines a conceptual framework of Information Systems that serves as a sound foundation for Software Engineering research. After reviewing previous proposals, the FRISCO report is taken as a starting point. The proposed conceptual framework defines a set of interrelated concepts about Information Systems. The result is a generic model of Information Systems. This generic model also serves as a reference ontology for the ontological evaluation of software development methods. A procedure for ontological evaluation named conceptual alignment is defined. Three software development methods are conceptually aligned as a proof of concept. Furthermore, the conceptual framework and the procedure for conceptual alignment are applied to the field of Method Engineering. A strategy for evaluating the ontological completeness of situational methods (methods designed as an assembly of methodological pieces in order to suit a particular situation) is proposed. Numerous examples and diagrams complement the text of this work.


4

I. Introduction

5

INDEX

I. . INTRODUCTION ................................................................................................. 9 1. MOTIVATION AND PROBLEM STATEMENT .................................................................11 2. WORK STYLE .........................................................................................................14 3. SUMMARY OF MAIN CONTRIBUTIONS .......................................................................17 4. DOCUMENT STRUCTURE .........................................................................................19

II. RELATED DISCIPLINES AND WORKS .......................................................... 21 1. INFORMATION SYSTEMS AND COMMUNICATION THEORY..........................................23

1.1. Shannon’s theory of communication ............................................ 25 1.2. Jakobson’s model of the communicative act ................................ 26

2. METHOD ENGINEERING ..........................................................................................28 2.1. Situational Method Engineering.................................................... 28 2.2. Contingency Theory...................................................................... 29 2.3. Wicked Problems.......................................................................... 30

3. ON ONTOLOGIES AND THEIR USES...........................................................................31 3.1. A formal scientific realist approach............................................... 34 3.2. A common-sense realist approach ............................................... 35 3.3. Constructivist approaches ............................................................ 37 3.4. Comparison of approaches: my own epistemological stance ...... 39

4. ON THE EVALUATION AND COMPARISON OF MODELLING TECHNIQUES AND SOFTWARE DEVELOPMENT METHODS...................................................................................................43

4.1. Ontological evaluation of software development methods ........... 45 5. CONCLUSIONS ON THE REVIEW OF RELATED WORKS ...............................................49

III. A GENERIC MODEL OF INFORMATION SYSTEMS...................................... 51 1. INTRODUCTION.......................................................................................................53 2. FROM ISO87 TO FRISCO: IT IS ALL ABOUT COMMUNICATION..................................54 3. DEFINITIONS BORROWED FROM FRISCO ................................................................56 4. NOTATION..............................................................................................................57 5. A GENERIC MODEL OF INFORMATION SYSTEMS .......................................................59

5.1. The Information System Memory.................................................. 61 5.2. Envisioning the Interface as a Message Editor ............................ 61 5.3. The Information System Reaction ................................................ 62 5.4. The Organisational System Reaction ........................................... 62

6. THE IS INTERFACE VIEWED AS A MESSAGE EDITOR (AND DISPLAYER).......................64 7. ACKNOWLEDGEMENT OF SOME LIMITATIONS OF THE CONCEPTUAL FRAMEWORK ......68

IV. UNDERSTANDING HOW INFORMATION SYSTEMS ARE DESCRIBED ..... 71 1. DISCOVERY AND DESCRIPTION OF REALITY .............................................................72


6

2. ON PERSPECTIVES AND DECOMPOSITIONS...............................................................74 2.1. Perspectives..................................................................................74 2.2. Decompositions and localised decompositions ............................75

3. CONCEPTUAL ALIGNMENT OF SOFTWARE DEVELOPMENT METHODS..........................77 4. PRACTICAL APPLICATION OF CONCEPTUAL ALIGNMENT ...........................................78 5. THE RATIONAL UNIFIED PROCESS ..........................................................................80

5.1. RUP at a glance............................................................................80 5.2. Conceptual alignment of the high abstraction models of the RUP82

5.2.1. Business Use Case Model............................................................82 5.2.2. Business Analysis Model ..............................................................83 5.2.3. Use-Case Model ...........................................................................87 5.2.4. Analysis Model ..............................................................................88

6. THE WISDOM METHOD..........................................................................................91 6.1. Wisdom at a glance.......................................................................91 6.2. Conceptual alignment of some Wisdom models...........................92

6.2.1. Requirements Workflow................................................................93 6.2.2. Analysis Workflow.........................................................................96 6.2.3. Design Workflow ...........................................................................97

7. OO-METHOD .....................................................................................................101 7.1. The OO-Method at a glance .......................................................101 7.2. Conceptual alignment of some OO-Method models...................102

7.2.1. Requirements Model...................................................................102 7.2.2. Conceptual Model .......................................................................107

7.3. Some comments on the OO-Method and the MDA....................117 8. FURTHER ARGUMENTATION ..................................................................................125

V..ON THE ONTOLOGICAL COMPLETENESS OF SITUATIONAL METHODS....129

1. MOTIVATION.........................................................................................................131 2. RELATED WORKS ON METHOD COMPLETENESS......................................................132 3. EVALUATION OF THE ONTOLOGICAL COMPLETENESS OF A SITUATIONAL METHOD ..134

3.1. Generic proposal.........................................................................134 3.2. Application of the proposal to a Method Engineering framework138

4. FURTHER ARGUMENTATION ..................................................................................144 VI. CONCLUSIONS AND FUTURE WORK..........................................................145

1. CONCLUSIONS......................................................................................................147 2. FUTURE WORK .....................................................................................................149

VII. APPENDICES............................................................................................151 A. EARLY VERSIONS OF THE GENERIC IS MODEL, USING UML CLASS DIAGRAM NOTATION 152 B. SUMMARY OF THE OO-METHOD CONCEPTUAL ALIGNMENT ....................................155 C. SUMMARY OF BWW ONTOLOGICAL CONCEPTS......................................................156

I. Introduction

7

D. SUMMARY OF CHISHOLM’S ONTOLOGICAL CONCEPTS............................................158 E. SUMMARY OF FRISCO ONTOLOGICAL CONCEPTS .................................................160 F. A TECHNIQUE TO MODEL INTERACTION REQUIREMENTS IN THE OO-METHOD ..........168

VIII. REFERENCES .......................................................................................... 175


8

I. Introduction

9

I. INTRODUCTION


10

I. Introduction

11

1. Motivation and problem statement

This work arises from the necessity of having a theoretical framework that serve as a sound foundation for our research in the Software Engineering field. We1 are convinced that the concepts that are used in research literature have to be rigorously defined. In order to define a set of interrelated concepts we took into account previous efforts done by the Software Engineering community. This work is specifically focused on organisational Information Systems. Why is an Information Systems (ISs) conceptual framework needed? There is an uncountable quantity of literature about ISs both from the academic community and the industrial community. Different authors give different names to the same concept. Although it would be easier for the reader if a common terminology was agreed, this will never occur for obvious reasons. In any case, the variety of terms is not necessarily a problem as long as each author specifies their meaning and keeps it consistent throughout its work. That is, the same way that a roadmap is often accompanied by a legend that helps to interpret the symbols being used in the map, research and practice papers should do the same, not only with the notations they use, but also with the terms being mentioned. An ISs conceptual framework serves to prevent terminological confusion. Also, it sets a sound conceptual foundation in top of which further research can be built. By studying in detail what elements constitute an Information System (IS) several benefits are expected.

• Developing a conceptual framework about Information Systems allows us to gain deeper knowledge about Information Systems. This can be confirmed by assessing that the IS conceptual contributes with new ideas or insights on the area.

• Developing a conceptual framework about Information Systems allows a better understanding of how Information Systems are computerised. This can be confirmed by assessing that the IS conceptual framework serves as a basis to define a technique for evaluating software development methods.

What is a software development method? It should be easy to answer such an apparently simple question. But if we ask this (apparently) simple question to either an academic or an industrial audience, there will probably be as many different answers as people. Again, if we add some simple adjectives, such as correct, or complete, or efficient (in relation to the software development method they describe), things will get even worse. The fact is that, after several decades of intensive theoretical and practical work, properly characterizing a specific software development method is still a very difficult task. Why is it so complicated? Even though we obtained a huge number of different answers, we could conclude that there is some basic agreement on the fundamentals. No matter how a 1 This work is the Master Thesis of Sergio España. However, throughout the document, the first person of the plural is often used. This is both a stylistic resource and my acknowledgement to my supervisors and the colleagues who I work with. I see research as a joint effort to pursue an ever-growing body of knowledge that is shared with, at least, the scientific community.


12

software development method is defined, there is a set of phases that include a higher-level phase that deals with Requirements Elicitation, a subsequent phase that deals with Conceptual Modelling, and a lower-abstraction level phase that is oriented to Design and Implementation. However, even if this generic structure is accepted, things remain complex. If we refer to Requirements Modelling, there is a confusing disagreement when Requirements Elicitation is related to Business Modelling, or Business Process Modelling, or even Organisational Modelling. There are early and late requirements, different concepts and notations for business process modelling, goal-oriented techniques (KAOS, i*), scenario-oriented approaches (most of which are use case-based); the list could go on. When an attempt is made to obtain a conceptual schema from any of these higher-level models, too many questions arise: how can a conceptual schema be derived from a requirements model? What if the process is started from a goal-oriented model? Is a functional, use case-based model ever useful in accomplishing this model transformation? How can non-functional requirements be properly represented? Can a goal model be directly transformed into a conceptual schema? Should this conceptual schema be object-oriented for the sake of understandability? Does it make sense to use aspect-oriented technology? If so, at what level2? Is object-oriented more convenient than aspect-oriented or vice versa? Or should both orientations be ignored? There are specific software development processes that are designed to provide an operational answer to the need for an appropriate solution. Normally, they come under the label of methods, and are based on a chosen paradigm. Examples of these are the OO-Method [Pastor, Gómez et al. 2001] for an object-oriented method; Tropos [Bresciani, Perini et al. 2004] for an agent-oriented method; Early Aspects [Moreira, Rashid et al. 2005; Baniassad, Clements et al. 2006] for an aspects-based proposal; and some generic proposals (normally based on the UML [OMG 2005c]) which include the RUP [Jacobson, Booch et al. 1999] and Wisdom [Nunes and Cunha 2000]. Finally, there are a myriad of specific techniques and methodological guidelines to deal with different parts of the process. However, many of the concepts and criteria of use that these methods provide tend to be vague, when not completely inadequate to properly reason unambiguously about IS. Concepts as information system, organisation, message, actor, action, event, conceptual schema, service, method, function, use case, interaction, value, goal, are often treated in an unclear way. The fuzziness with which software development methods are described makes it rather difficult to compare their different proposals in a systematic way, or even to understand them fully in order to enact them. More than ever, it is necessary to concentrate on the essentials of Information Systems (ISs) modelling. A set of precise concepts is essential to be able to understand what each technique offers. A conceptual reference framework that is based on a set of relevant and significant concepts is needed to confront this methodological Tower of Babel. One of the most relevant challenges for Information Systems research is to correctly understand the essentials of its underlying theory. By that we mean to

2 The use of early aspects to deal with requirements generates aspect-oriented conceptual models.

I. Introduction

13

understand the basic concepts that act as building blocks of any system description. In this context, we believe that Ontology plays a fundamental role. Beyond being the new buzzword in Computer Science, and beyond its successful use as the backbone in modern areas as Semantic Web, we have been working on how ontologies3 (even simple ones) help to precisely define the basic concepts that are required to characterise ISs. The use of basic frameworks of reference is a well-known, successful strategy that is widely used in sound ISs research. For instance, a basic framework for performance engineering during ISs development is proposed in [Opdahl and Sølvberg 1992b]. The strategy of IS modelling presented in [Opdahl and Sølvberg 1992a] has been properly adapted to the context and objectives of our work. Since the inherent complexity of ISs is in the origin of the definition of diverse software development methods, and since different methods view ISs design and implementation from different perspectives, our goal is to identify a basic set of concepts of reference. In this work, we take an ontological approach and define a conceptual framework for ISs that establishes a set of concepts. This concepts help to understand what an IS is by abstracting its elements. Instead of starting from scratch, the FRISCO proposal is taken as a starting point [Falkenberg, Hesse et al. 1998]. This framework is then used to characterise the different perspectives, strategies, and views of a given method. This characterisation is called a conceptual alignment of a method with respect to the proposed framework, which shows how a given method relates to the basic concepts of our framework. This framework can be used to classify any software production method from a unified conceptual base. The conceptual alignment allows arguing about the strengths and problems of a particular method. Also remarkable is the fact that we could compare several methods and, consequently, discuss about the potential benefits and drawbacks of each method (though this comparison to one another is yet to be done). This comparison will also help us to understand the current situation of Software Engineering and to propose future lines of research from a very precise and well-analyzed context. We argue that reasoning about the ontology that underlies the development of software is of much value for the Software Engineering community, since it allows gaining deeper knowledge of this area, and that it also benefits the Ontology community because it focuses on some practical needs concerning software development methodologies.

3 The conceptual framework proposed in this work can be seen (and is referred to) as an ontology about ISs.


14

2. Work style

This work is mainly theoretical. A framework of concepts related to Information Systems has been built. To do that, a review of related works has been done. Then a starting point has been established and a sequence of tasks has been iterated until the framework has achieved coherence and stability (see Figure 1).

1. Review of previous conceptual frameworks. A review of the literature on Information Systems conceptual frameworks and ontologies has been done. Also, a body of knowledge about theory of communication, information systems, organisational management and conceptual modelling has been gathered.

2. Consider adopting an existing framework. Among the previously existing conceptual frameworks, one has been finally adopted and taken as a starting point. This way we benefit from a corpus of well defined concepts built by experts in the matter.

3. Analysis of conceptual needs. The conceptual framework is analysed to determine potential improvements. This is carried out by means of epistemological review of related literature and considering the participants’ knowledge about Information Systems. An unstructured list of needs is created in this task.

4. Proposal of concepts and relations. A set of concepts and relations among them is proposed. Each participant drafts a definition of each concept and draws a preliminary diagram depicting the information system elements being proposed.

5. Discussion of the proposal. The proposal is debated by the participants, focusing on the appropriateness of each concept or relation and the clarity of its definition. Often, the concepts are redefined to improve their precision and diagrams are redrawn to improve their understanding.

6. Search for agreement. Whenever the participants have different points of view on some matter, agreement is sought by acknowledging the pros and cons of each point of view. In case of conflict, the participants try to keep the framework both expressive and simple.

7. Update the framework. The conceptual framework is updated by means of incorporating new concepts and relations, redefining some previously existing concepts and redrawing affected diagrams.

Figure 1 shows the explained workstyle. Three participants have been involved in the process of defining the conceptual framework. As a conceptual framework is neither true nor false, but convenient for a certain purpose or not, it can never be considered finished in an objective way. Arbitrarily, it has to be packed and shared with the research community at some point of the time. Around a dozen iterations have been done to achieve the framework presented in this work.

I. Introduction

15

Figure 1. Workstyle for the definition of the Information Systems conceptual framework

In relation to the conceptual alignment of software production methods, a similar workstyle has been followed:

1. Determine method to be evaluated. The method is chosen based on one or several of the following criteria: the relevance of the method (how well known it is), the convenience for illustrating the conceptual framework elements (e.g. a method that proposes interaction modelling allows discussing about those elements of the conceptual framework that are related to the Information System interface).

2. Review of method descriptions, guidelines and examples. A set of papers, books and manuals about the selected method is compiled. Specific guidelines about the modelling techniques are included. Also, case studies and examples available in the research literature or reliable websites are stored.

3. Development of example models. A practical example is built using the method; that is to say, a model of an Information System is created following the guidelines proposed by the method. When possible, a widely-known example has been adapted; that is, an example that appears in the literature is modified to avoid unnecessary details and to ensure that all the expressiveness of the modelling techniques is shown. When necessary, a new example has been developed.

4. Analysis of potential mappings. The documentation about the method is carefully analysed to identify the modelling primitives proposed by the method. In this task, both the description of the method and the example model are taken as input. A preliminary set of mappings between modelling primitives and elements of the conceptual framework is defined.

5. Proposal of conceptual alignment. A conceptual alignment of the method is proposed and specified in a document. The example model is used as a medium through which the mapping is explained; that is, the mapping is represented drawing arrows between elements of the example


16

model and elements of a graphical representation of the Information Systems conceptual framework. This is done this way for pragmatic reasons.

6. Discussion of the proposal. The proposal of conceptual alignment is debated by the participants, focussing on the accuracy of each mapping: assessing whether the modelling primitive is actually intended to represent the element of the Information System that the primitive is mapped to.

7. Search for agreement. Whenever the participants have different points of view on some mapping of the conceptual alignment, agreement is sought by retrieving the method description and the compiled guidelines and examples in order to ascertain the precise meaning of the modelling primitive. In case method descriptions offer ambiguous or contradictory definitions of the modelling primitive, the participants are forced to take a decision taking into account which definition is more widely followed in practice.

8. Update the conceptual alignment. The conceptual alignment is updated by means of incorporating new mappings and explanations, redefining some previously existing mappings and redrawing affected graphical views of the conceptual alignment.

Figure 2. Workstyle for the definition of the conceptual alignment of a given method

Figure 2 shows the workstyle that has been followed to determine the conceptual alignment of a given method. Three participants intervened on this process. Since it is based on interpretation, around four iterations were needed to agree on the mappings between the modelling primitives of the framework and the elements of the Information Systems conceptual framework.

I. Introduction

17

3. Summary of main contributions

This work claims to provide the following contributions: • A conceptual framework for Information Systems that starts from (and

enriches) the FRISCO proposal from an ontological perspective is presented in previous work [España 2007]. Now, the framework is revisited and extended: some concepts are redefined, new explanations and examples are added, new concepts are included and new diagrams contribute to clarify the framework. The result of this extension is a generic model of Information Systems.

• Since facing the problem of user interface specification is a basic issue to understand ISs, another contribution is an in-depth analysis of Information Systems interfaces; this leads to the inclusion of interaction-oriented aspects in the conceptual framework. This extension of the framework is a novel work. For some of the issues tackled in this extension there is no evidence showing that they have been addressed by previous conceptual frameworks.

• The introduction of the strategy of Conceptual Alignment as a major application of the previous framework, intended to understand the semantics that is behind any software production method. It consists on defining precise mappings between the modelling primitives proposed by a given method and the ontological concepts of the conceptual framework. This strategy, presented in previous work [España 2007], is now revisited and clarified.

• The practical application of the framework to conceptually align the concepts of several software development methods, to demonstrate the previous ideas. Find more details below.

• The definition of a strategy to evaluate the ontological completeness of situational methods. Method Engineering offers a paradigm in which methods are designed as an assembly of method fragments. The strategy presented in this work integrates the generic model of Information Systems and the conceptual alignment with a framework for Method Engineering. The result of this integration is a strategy that allows to evaluate the ontological completeness of an assembled method, given a particular project situation.

A conceptual alignment is a careful analysis of the concepts that underlie the modelling primitives proposed by a given method. In this work, we have chosen the following methods:

• The Rational Unified Process [Rational 2003], a well-known and widely used software process. The RUP is a commercial product developed and marketed by Rational Rose4, an IBM company. This alignment was presented in previous work [España 2007]; now some minor changes are done to its presentation.

4 IBM Rational Software. http://www-306.ibm.com/software/rational/ - Last visit: 01-2007


18

• The Wisdom method [Nunes and Cunha 2000]. Wisdom is an interesting attempt to combine functional-oriented UML-based models with user interface specification techniques. Wisdom instantiates and extends the Rational Unified Process [Rational 2003] by providing modelling primitives that deal with the interaction between users and the system under development. This conceptual alignment shows the utility of the interface-related extension of the Information Systems conceptual framework.

• The OO-Method [Pastor, Gómez et al. 2001], which is a Conceptual Schema-Centric Software Development Method, that was developed at the Valencia University of Technology and that has been implemented commercially5. A previous conceptual alignment of OO-Method is presented in previous work [España 2007]; now the conceptual alignment is redone with respect to the extended conceptual framework. This way, the conceptual primitives related to the specification of the interface are precisely mapped to interface-related concepts. Also, OO-Method techniques for (functional and interaction) requirements elicitation are conceptually aligned.

The conclusions obtained from the use of this framework are relevant because it highlights the various limitations of current software development methods. It also helps to clarify frequent misunderstandings that can be found in the literature, and it identifies deficiencies in the underlying criteria. For example, most methods offer poor communicational analysis of the IS. Communication is not always properly considered. Managing communication properly in ISs development is fundamental, especially in the current socio-economic context where ISs are more and more complex and need to be properly integrated and aligned with organisational needs. The conceptual framework presented in this work offers valuable insights on Information systems.

5 The OLIVANOVA suite includes a conceptual modelling tool and a model compiler. It has been developed by CARE Technologies. http://www.care-t.com - Last visit: 02-2008

I. Introduction

19

4. Document structure

This work is structured as follows. • Section II presents a study of related disciplines. The relation between ISs

and Theory of Communication is described. Method engineering is explained and its relation with Contingency Theory and wicked problems is clarified. This section also reviews works related to the major contribution of this work. The role of Ontology in the field of ISs is explored (differentiating approaches depending on their philosophical stance). Also, software development method evaluation techniques are reviewed. The focus is put on ontological evaluation.

• Section III introduces the Information Systems conceptual framework. First, the basis of the reference conceptual framework is presented; the FRISCO report proposal is extended in order to build an ISs conceptual framework. Also, the focus is put on how the interface can be viewed as a message editor, taking a communicational approach to the issue. As a result, the ISs ontology is further extended to address the complex process of building messages. The limitations of the conceptual framework are acknowledged.

• Section IV presents some considerations on how reality is described via perspectives and decompositions; this analysis establishes some concepts that are useful to reason about software development methods. A technique for the conceptual alignment of software development methods is introduced. Several methods are conceptually aligned: OO-Method, the Rational Unified Process and the Wisdom method. Both the conceptual alignment and a case study using the each method are presented.

• Section V presents a budding application of the ISs conceptual framework and the conceptual alignment to the field of Method Engineering. The completeness of situational methods can be assessed with the aid of the ISs ontology.

• Section VI presents the conclusions and discusses future work. • Several appendices complement this work by offering additional

information and explanations.

II. Related disciplines and worksworks

21

II. RELATED DISCIPLINES AND WORKS


22


23

1. Information Systems and Communication Theory

Systems Theory is widely accepted as a development paradigm for theories related to complex phenomena. An observer who is interested in conceiving of a series of phenomena as a system marks out a portion of the world (encapsulates the system) and chooses a set of modelling languages to describe the system. Some properties of the system cannot be understood (or explained) by simply studying system components; these properties, which are called emergent properties, appear when the components of a system interact. The appropriate way of analyzing a system is by studying its interaction with its environment. An Information System (IS) is a subsystem of an Organisational System (OS) (see Figure 3). The environment of the IS is both the OS and the Subject System. The aim of the IS is to support the communication of the OS with the environment as well as the communication within the OS. Therefore, the main type of interaction to be considered in an IS is a communicative interaction.

Figure 3. The context of organisational management Information Systems

Interactions that occur between the IS and its environment may well be considered from different granularities. The granularity with which we perceive phenomena depends on the goals of the actors involved. These goals change depending on two related aspects: context and time. The goals of each actor who is affected by a communicative interaction are conditioned by the actor’s responsibilities.

1. From the point of view of support (the Computerised IS), functions are related to Shannon’s model of communication: encoding, transmission (via a channel), and decoding [Shannon 1948]. See Figure 4 for a diagram of Shannon’s model of communication. The transmitter and the receiver must share a code, which is used to encode and decode the message.


24

Figure 4. Adaptation of Shannon’s model of communication

2. From the point of view of the IS, an actor’s responsibilities are oriented to informational functions. The aim of an IS is to collect, store, recover, treat and distribute information with a specific purpose [Langefors 1977]. The communicative conception of the IS is expressed as informational functions. The purpose of the communication that is being supported by the IS depends on the mission of the OS.

Figure 5. Adaptation of Jakobson’s model of the communicative act

3. Commonly, the mission of the OS is to observe and influence the behaviour of a Subject System that is of interested to the OS. Then, from the organisational point of view, the goals are related to the organisational responsibilities triggered by the facts that are being reported. Each new message must be delivered to the appropriate actors so that they can react in accordance with the meaning conferred to the message [Jakobson 1990]. An important implication of Jakobson's theory is that meaning emerges from the total communicative act and it is not a stable entity that resides in the message per se. The model of the communicative act (see Figure 5)


25

also shows the importance of the communicative context (besides the shared code, a shared knowledge is needed).

4. The Subject System acts as the environment from where stimuli come. Figure 3 shows one possible imbrication among these systems and reflects the fact that (part of) the IS may be computerised. From the point of view of the Subject System, the goals are linked to autonomous behaviours (e.g. actions of the customer), some of which are recognised by the OS.

Each of these intentions can also be influenced by the temporal axis. Interactions can be considered from their immediate consequences to their final consequences. When a client places an order, s/he expects the goods to be delivered to his/her home in optimal conditions. However, other intentions are brought into play. The OS shares the client’s goals, but it adds some goals which are more immediate and communicative: the client’s order needs to be acquired and registered; manufacturing and assembly orders need to be sent to the workers, so that they can produce the goods or deliver the service. The acquisition process, which is related to the formulation and encoding of the message, is the most immediate goal. The IS must support the communication with and within the OS; the IS interface must support the edition and display of messages being communicated.

1.1. Shannon’s theory of communication

Shannon defines a model of communication that emphasises the role of encoders (transmitters) and decoders (receivers). He defines a communication system as a system of the type indicated schematically in Figure 6. It consists of essentially five parts:

• An information source which produces a message or sequence of messages to be communicated to the receiving terminal. E.g. the message may be a single function of time f(t) as in radio or telephony.

• A transmitter which operates on the message in some way to produce a signal suitable for transmission over the channel. E.g. in telephony this operation consists merely of changing sound pressure into a proportional electrical current.

• The channel is merely the medium used to transmit the signal from transmitter to receiver. E.g. it may be a pair of wires, a coaxial cable, a band of radio frequencies, a beam of light.

• The receiver ordinarily performs the inverse operation of that done by the transmitter, reconstructing the message from the signal.

• The destination is the person (or thing) for whom the message is intended. Additionally, he considers the possible existence of a noise source that perturbs the signal during transmission or at one or the other of the terminals. This means that the received signal is not necessarily the same as that sent out by the transmitter.


26

Figure 6. Schematic diagram of a general communication system (from [Shannon 1948])

Figure 4 revisits Shannon’s schematic diagram by graphically distinguishing the following types of elements6: actors are represented by triangles, actions are represented by squares, and actands are represented by circles. Actions do not appear explicitly in Shannon’s schematic diagram; namely, encode message, chanelling action, decode message. The existence of a shared code, although not explicit in Shannon’s schematic diagram, is needed in order to ensure that the messages at both sides of the transmission are the same. In Shannon’s model, shared code is referred to as the encoding function and its inverse.

1.2. Jakobson’s model of the communicative act

Jakobson has developed a model of the communicative act, taking into account the following elements [Jakobson 1990]:

• Addresser. This is the one who sends the message. It is also referred to as sender.

• Addressee. This is the one who is expected to receive the message. It can also be absent or implicit, during the communicative act. It is also referred to as receiver.

• Context. It is the referent or subject matter of the discourse, what it refers to. It also includes shared knowledge.

• Code. It contains information about the lexical code with which the message is built. It is fully or partly known to addresser and addressee (see shared code in Shannon’s model of communication). Codes need to be learnt.

• Contact. It refers to the channel or connection (physical or psychological) between the two parties.

6 Informally, actors are things capable of doing, actions are the things that actors do and actands are those things that serve as input for actions or that are the result of actions. See Apendix D for a more formal explanation of these terms.


27

• Message. It is the thing being conveyed; that is, the information being communicated.

Jakobson defines six possible functions of language that are closely interrelated. An utterance does not necessarily/usually have only one function. Nevertheless, it can be considered that, in each, communicative act, one function predominates. These functions are related to the six elements of the communicative act.

• Emotive function. It is the direct expression of the speaker's attitude toward what s/he is speaking about. It is related to the addresser. The purpose of this function is to convey emotion. Also referred to as expressive function. An example: -What a beautiful voice!-

• Connative function. It is related to the addressee. The purpose of this function is to convey commands; that is, the aim is to (attempt to) transform reality or people, to affect the course of events or behaviour of individuals. Therefore, it is not liable to a truth test (it is neither true nor false; it is an order or a suggestion). Also referred to as vocative or imperative function. -Hear her sing!-

• Referential function. It is related to the context. The purpose of this function is to convey information. In any case, human language is never completely neutral, so it is usually combined with other functions. Also referred to as informative function. An example: -Mary Fahl is singing.-

• Metalinguistic function. It is related to the code. The purpose of this function is to convey code analysis. Language is capable of self-interpretation. Also referred to as metalingual function. An example: -This is the concert programme.-

• Phatic function. It is related to the contact. The purpose of this function concerns contact, both at the physical and psychological levels. It aims to establish, maintain contact, and ensure operation of the channel of communication. Also referred to as contact function. An example: -Hello. Nice voice, huh?-

• Poetic function. It is related to the message. The purpose of this function is to convey play or pleasure. It aims to play with form (e.g. rhyme, repetition, alliteration) or meaning (e.g. artful exploitation of synonyms, metaphors). An example: -She sings like an angel.-


28

2. Method Engineering

During the 90s, the scientific community realised that organisations did not enact methods just as they are defined in method descriptions (e.g. books, manuals, methodological guidelines). Methods were used more laxly, they were adapted [Russo, Wynekoop et al. 1995]. This recognition started a trend to describe methods by means of fragments that can be assembled to fit a specific project or organisation. This was called Method Engineering. This section focuses on software development Method Engineering.

2.1. Situational Method Engineering

Method Engineering represents a structured framework in which methods for software development activities can be designed, constructed, and adapted. Methods are assembled from multiple individually identifiable parts, often referred to as “method fragments”, “method chunks” or “method components” [Henderson-Sellers, González-Perez et al. 2007] [Henderson-Sellers, Gonzalez-Perez et al. 2008]. Method fragments are defined as an instantiation of a metamodel and they are stored in a repository. A method designer (a.k.a. method engineer) assembles several method fragments in order to create a method7. Then, project managers can instantiate the method in order to enact the development process. Figure 7 shows an overview of these ideas.

Method fragments/chunks/components

Repository

Methodology Instance

Step 2: Project Manager

Construction Guidelines

uses

Metamodel

instance of

instances of

Methodology M (a.k.a. Process Model)

Step 1: Method engineer

(a.k.a. Process) Figure 7. An overview of Method Engineering (from [Henderson-Sellers 2005])

7 Some authors, as well as the ISO/IECC 24744 report, use method and methodology as synonyms. However, in this work, we use the term method. Methodology is used to refer the study of methods or to qualify something as being related to methods (e.g. methodological guideline).


29

Situational Method Engineering is therefore the configuration of these resultant methods specifically for individual projects [Brinkkemper 1996] [Kumar and Welke 1992] [Ralyté, Brinkkemper et al. 2007]. This topic is especially relevant and useful in areas such as requirements engineering where various situation-specific factors, e.g. project objective, application domain, features of the product to be developed, stakeholders involved, and technological conditions and constraints, exert a significant influence [Ågerfalk and Ralyté 2006]. Ågerfalk and Ralyté have identified an initial and traditional assembly-based approach in method engineering [Ågerfalk and Ralyté 2006]. In their work the procedure has been used to describe methods and processes in meta-models to be used as a basis for computer supported instantiation of situational methods, typically through the assembly of a number of method fragments from different methods stored in a method base [Brinkkemper, Saeki et al. 1999] [Lyytinen and Welke 1999]. Recently, however, method engineering research and practice have extended beyond the traditional assembly-based approach to address a variety of issues including method requirements specification [Gupta and Prakash 2001], method configuration [Karlsson and Ågerfalk 2004] and roadmap-driven approaches [Mirbel and Ralyté 2005]. Recent works [Ågerfalk and Fitzgerald 2006] [Karlsson and Wistrand 2006] also pay more attention to method rationale (i.e. the reasons behind and arguments for the method) and the tension between method-in-concept (as described in method handbooks) and method-in-action (as enacted in actual engineering practice). Method Engineering concepts and metamodel are specified by the ISO/IEC 24744 report [ISO/IEC 2007].

2.2. Contingency Theory

The application of the contingency principle to the organisational area was introduced by Fiedler [Fiedler 1964]. In a time when many scholars assumed that there existed only one good leadership style, Fiedler proposed a model of contingency that defined leadership effectiveness depending on the interaction among several factors. This gave rise to a field of studies that tried to define the adequacy of a strategy to a situation. Contingency theory underlies Situational Method Engineering. For instance, Mirbel and Ralyté propose to characterise the project situation and the project engineer’s profile using several reuse frames. A “reuse frame contains the knowledge about the reuse context of […] method chunks and provides criteria for project and project engineer situation characterization.” [Mirbel and Ralyté 2005]. Figure 8 shows the contingency factor reuse frame. This tree is part of a bigger tree corresponding to the whole reuse frame, including organisational, human and application domain characteristics.


30

Figure 8. Contingency factor reuse frame (from [Mirbel and Ralyté 2005])

2.3. Wicked Problems

In the area of ISs we often have to deal with so-called ‘wicked problems’. Wicked problems are often not fully understood until a solution has been found, since every wicked problem is essentially unique and novel. Solutions to these problems are not right or wrong, simply "better," "worse," "good enough," or "not good enough” [Rittel and Webber 1973]. Indeed, it is the social complexity of these problems, not their technical complexity, which overwhelms most current problem-solving approaches. To appropriately deal with wicked problems, it is common to carry out opportunity driven problem solving. At any given time the developers are seeking the best opportunity to progress toward a solution, regardless of whether they are going up or down in the abstraction ladder. Rittel identified a type of problematic situation that can only be solved if representatives of all the stakeholders participate in a joint effort [Rittel and Webber 1973]. Models are specifications of the shared knowledge about the problem and they serve as an agreement. Therefore, it is important that some specific models are understandable for the users. The consequence of this tangle of cognitive, social and abstraction-level issues is that no single ingenuous solution is adequate. Methodologists need to offer software-development methods that facilitate opportunity-driven problem solving. An evident corollary is that it is important to deal with contingency in software development. Methods must be flexible in the sense that the techniques to be applied in each moment are determined by various factors: the characteristics of the system to be computerised (i.e., automatic teller machines are not dealt with the same way as ISs), the nature of a specific problem presented at a given moment (e.g. to design a user interface, to specify business objects, to design strategic-level reports), the expertise of the development team (which techniques they know best), the maturity of the organisational system, the users’ organisational and technological knowledge, the predisposition of the stakeholders to be involved in development, etc.


31

3. On ontologies and their uses

An ontology, in the philosophical sense, is a systematic explanation of existence, as it is perceived by humans. Ontology is a well established branch of Philosophy that deals with understanding elements of the world. The basis for an ontology is a fixed terminology in order to refer to entities of a particular domain. On top of this terminology, a conceptualisation can be built. According to Gruber [Gruber 1995], ontologies need the following elements in order to represent knowledge:

1. Concepts. These elements are the basic ideas that are being formalised. Concepts can refer to physical things of the world (e.g. objects), as well as to abstract things (e.g. methods, plans, cognitive processes). These things are dealt with by abstracting them with the notion of class (e.g. class of objects).

2. Relations. These elements represent interactions and links among concepts. This way, a taxonomy is built. According to Gruber, main relations are subclass-of, part-of, connected-to.

3. Functions. These elements are a specific type of relation in which an element of the ontology is identified by means of (operating with) other elements.

4. Instances. These elements are used to represent specific occurrences of concepts.

5. Axioms. These elements are theorems that specify relations that the elements of an ontology must satisfy. They are used to define ontology elements and to restrict the interpretation of their meaning.

Meaning is a key point in ontologies. In short, “ontologies consist of a vocabulary along with some specification of the meaning or semantics of the terminology within the vocabulary” [Fox and Gruninger 1998]. Milton and Kazmierczak quote Honderich’s definition of ontology:

“Ontology, understood as a branch of metaphysics, is the science of being in general, embracing such issues as the nature of existence and the categorical structure of reality. ... Different systems of ontology propose alternative categorical schemes. A categorical scheme typically exhibits a hierarchical structure, with ‘being’ or ‘entity’ as the topmost category, embracing everything that exists”. [Milton and Kazmierczak 2004]

Also, they state that the following elements are needed in order to describe an ontology:

1. A categorisation of what constitutes reality, and what fundamental categories of things exist. This could be represented as a taxonomy.

2. A set of terms, each associated with a concept that fully defines the term, with which to construct descriptions of ‘what there is’.

3. A set of fundamental terms labelling the fundamental categories (in 1) and a means of relating all terms back to those labelling the fundamental categories.


32

McGuinness offers a linear spectrum of ontologies8 (see Figure 9), depending on the characteristic of the ontology and the level of detail of its specification.

Figure 9. An ontology spectrum (from [McGuinness 2003])

McGuinness considers the existence of the following types of ontologies [McGuinness 2003]:

• Catalogue. A controlled vocabulary; that is, a finite list of terms. Catalogues can provide an unambiguous interpretation of terms by linking them to identifiers.

• Glossary. A list of terms and their definitions9. The definitions are specified typically as natural language statements. This provides a kind of semantics since humans can read the natural language statements and interpret them, although not always unambiguously. Therefore, these specifications are not adequate for computer agents.

• Thesauri. A list of interrelated terms and their definitions. Relations between terms provide information such as synonym relationships. Typically thesauri do not provide an explicit hierarchy, but a relation among narrower and broader terms.

• Informal is-a ontologies. Some ontologies provide an explicit hierarchy. In these cases, an instance of a more specific class is an instance of the more general class but that is not enforced 100% of the time.

• Formal is-a otology. It provides an explicit hierarchy where an instance of a more specific class is always an instance of the more general class. Strict subclass hierarchies are necessary for exploitation of inheritance.

• Formal instance ontologies. These ontologies include formal instance relationships. Some classification schemes only include class names while others include ground individual content.

• Frames ontologies. In these ontologies, classes include property information. Properties become more useful when they are specified at a general class level and then inherited consistently by subclasses and instances.

• Value restriction ontologies. The ontology includes restrictions on what can fill a property. For example, we may want to fill in the value of one property based on a mathematical equation using values from other properties.

8 In the paper, McGuinness focuses on web ontologies, but her reasoning is still valid for other kind of ontologies. 9 McGuinness uses the term meaning. However, from a semiotic point of view, the description of a term does not provide meaning to the term, it provides a definition.


33

• General logical constraints ontologies. These ontologies include arbitrary logical statements. They allow the specification of first order logic constraints between terms.

• Most detailed ontologies. These ontologies include relationships such as disjoint classes, disjoint coverings, inverse relationships, part-whole relationships, etc.

McGuiness requires the following properties to hold in order to consider something an ontology:

• Simple ontologies. o Finite controlled (extensible) vocabulary o Unambiguous interpretation of classes and term relationships o Strict hierarchical subclass relationships between classes

• Frame-based ontologies. o Property specification on a per-class basis o Individual inclusion in the ontology o Value restriction specification on a per-class basis

• Logic-based ontologies. o Specification of disjoint classes o Specification of arbitrary logical relationships between terms o Distinguished relationships such as inverse and part-whole

Independently of their level of detail, ontologies are applied to diverse areas of knowledge (e.g. philosophy; high-tech industries; financial, medical, educational, and agricultural sectors; computer science, information science, and business schools) with different intentions (e.g. for communication, for computational inference, for reuse and organisation of knowledge) [Grüninger and Lee 2002]. Among these areas of knowledge, this work focuses on the use of ontologies for computer science. Research on ontology is becoming increasingly widespread in this community. Guarino reviews some fields, within computer science, in which the importance of ontologies is being recognised: knowledge engineering, knowledge representation, qualitative modelling, language engineering, database design, information modelling, information integration, object-oriented analysis, information retrieval and extraction, knowledge management and organisation, agent-based systems design [Guarino 1998]. Within computer science, this work focuses on the application of ontologies to Information Systems and their computerisation. Barchini et al. identify the following roles of ontologies applied to Information Systems [Barchini, Álvarez et al. 2007]:

• A support for conceptual analysis of methods and techniques oriented to ISs development.

• A support for analysis, design, development and usage of Information Systems. Under this role, two perspectives are identified:

o The point of view of developers. It concerns the way in which the ontology facilitates (or is used for) developing Information Systems


34

o The point of view of the user. It concerns the way in which the ontology facilitates the user interaction with (and operation of) the Information System.

In this work, we define three categories of approaches to Ontology, depending on the philosophical stance of the authors: formal scientific realist approaches, common-sense realist approaches and constructivist approaches.

3.1. A formal scientific realist approach

Mario Bunge is the author of the philosophical ontology that has been most influential in ISs research [Bunge 1977; Bunge 1979]. This ontology adopts a scientific realist approach that requires a deep and detailed comprehension of contemporary science reality. He assumes that the universe is a world of interconnected systems. His philosophical theories in his Treatise on Basic Philosophy are formulated in a mathematical language (definitions, axioms, corollaries), so that they are consistent with contemporary science. He presents the basic notions of substance, property, thing, possibility, change, space and time, as well as wholeness (or systemicity), variety and change. An important step forward in the use of ontology in the context of IS analysis is done by Wand and Weber. They researched the branch of philosophy known as Ontology as a foundation for understanding the process of developing an IS. They based their work in the same epistemological stance as Bunge and built an ontological model: the Bunge-Wand-Weber (BWW) model [Wand and Weber 1990; Wand, Monarchi et al. 1995; Weber 1997; Weber 1999]. This model decomposes ISs in a way that is formal, free of content. The BWW system consists of three models [Weber 1997]: the representation model, the state-tracking model, and the good-decomposition model. The representation model tries to address the question whether a modelling technique contains all the modelling primitives that are needed to be able to represent any phenomenon in the Subject System (real world). The state-tracking model concerns the necessary and sufficient conditions for an IS to track events in the Subject System that it is intended to represent. The good-decomposition model addresses the question of whether it is possible to structure scripts in particular ways to facilitate communication of meaning to their reader, which depends on how we decide to decompose a system [Weber 1997]. Basically, they consider an IS to be, in essence, a representation of real world phenomena. The BWW model is based on two fundamental elements: things that exist in the real world and their properties. Figure 10 shows a model10 of BWW ontological concepts extracted from the work of Davies, Green, Milton, and Rosemann. Every thing in the real world possesses at least one property and every property belongs to at least one thing. Generalisations are qualified as either disjoint (d) or non-disjoint (n), total (t) or partial (p). Things are composite or simple. A composite thing is associated with at least two other things. A simple thing is comprised of only itself. Properties can be divided into sub-properties. A property can be a property in general or a property in particular (the later being an instance of the former). Also, a property can be an intrinsic property (one that is inherent in an 10 The authors (i.e. Green et al.) refer to the model as a metamodel. However, this is arguable, since it is actually a model of the BWW ontology that can serve as a metamodel for models of the real world.


35

individual thing) or a mutual property (one that is shared by two or more things). Attributes are used to name and represent the properties that humans wish to model. The BWW model includes some ontological concepts that are not included in Figure 10. Appendix C summarises the ontological concepts of the BWW model.

Figure 10. Model of BWW ontological concepts (from [Davies, Green et al. 2003])

Method designers can take advantage of the formality of ontologies to support the design of a new method. For instance, a conceptual model-based software production process called OO-Method [Pastor 1992; Pastor, Gómez et al. 2001] is built on top of a formal, object-oriented specification language called OASIS [Pastor, Hayes et al. 1992] that provides a precise definition of concepts based on an adapted version of the BWW model. That way, an ontological perspective of the Object-Oriented Model (called the O3 model) is used to determine the basic concepts on top of which the OO-Method is designed.

3.2. A common-sense realist approach

A philosopher called Chisholm proposed an ontology, adopting a critical common sense epistemological stance [Chisholm 1996]. Critical common sense demands a rigorous knowledge acquisition support standard. Milton and Kazmierczak claim that Chisholm’s ontology is, by itself, an ontological model of ISs [Milton and Kazmierczak 1999] [Milton, Kazmierczak et al. 2001]. Chisholm proposes an ontology that views the world as a collection of individuals and relations between them. Attributes describe both individuals and relations. Classes of individuals are related to each other by means of the intersections and unions of the attributes used to select those individuals.


36

Figure 11. The categories for Chisholm’s Ontology11 [Chisholm 1996]

Figure 11 shows a tree of categories (a.k.a. classes) from Chisholm’s ontology. This tree is a taxonomy. Individuals and attributes are central to the ontology; other categories are explained in terms of individuals and attributes. Individuals are considered contingent entities. Individuals exemplify and exhibit properties. Individuals are considered transient objects that come into being and pass away; that is, they are created and destroyed (thus, they have a lifespan). Individuals need not be material or physical in nature. Individuals may also be structured into constituents or parts (which are also individuals).

Figure 12. Model of Chisholm’s ontology (from [Davies, Green et al. 2003])

Davies, Green, Milton and Rosemann have created a model12 of Chisholm’s ontology and this model is shown in Figure 12. Each individual is identified by one or more attributes that it also exemplifies. Also, an individual may exemplify several more attributes. Note that, unlike the BWW model, Chisholm’s ontology loosely couples attributes and individuals. He considers that individuals are transient while attributes are enduring. Attributes are either simple or compound (an attribute that is composed of other attributes). Two or more attributes may share the relationship

11 Entia stands for Entities 12 The comment in footnote 10, , is also applicable to the model of Chisholm’s ontology.


37

of conceptual entailment; that is, when an individual exhibits a given attribute it necessarily exhibits the other. Other ontological concepts from Chisholm’s ontology are not present in Figure 12. Appendix D summarises the main ontological concepts of Chisholm’s ontology.

3.3. Constructivist approaches

In 1988, several scientists of Western and Northern European countries founded the IFIP WG 8.1 Task Group “FRamework of Information System Concepts” (FRISCO) with the aim "to provide a suitable conceptual framework, i.e. wherever possible, simple, clear and unambiguous definitions of, and a suitable terminology for the most fundamental concepts in the information systems field” [Falkenberg, Hesse et al. 1998]. The main outcome of the task group is the FRISCO report [Falkenberg, Hesse et al. 1998]. The FRISCO authors try to avoid a techno-centric view of the area and aim for a broad, interdisciplinary approach. Among the major achievements of the FRISCO report are the following [Hesse and Verrijn-Stuart 2000].

• It builds on a solid basis formed by semiotics and ontology. • It defines a collection of more than 100 core concepts in a coherent and

consistent way. • Information systems are more than just pure technical artefacts. FRISCO

introduces an interdisciplinary, socio-technical view of information systems. The FRISCO approach bridges the gap between reality and its modelling concepts basing their line of argument on semiotics, i.e. the theory of signs, their form (syntax), meaning (semantics) and effect (pragmatics) [Hesse and Verrijn-Stuart 2000]. FRISCO proposes a semiotic tetrahedron that unites elements from Ogden’s representational triangle and Pierce’s semiotic triangle.

Figure 13. The semiotic tetrahedron of FRISCO

The tetrahedron reflects the constructivist stance of FRISCO; the actor is made explicit (in the process of conferring meaning to a sign, the actor is a major element). Representation is the physical form that a sign shows (e.g. a stick figure doodled over a paper). The domain or referent is the object that the sign references; the representation substitutes the domain object in a model (e.g. a child’s drawing). The actor of the conceptualisation process acts as a systemic


38

observer. The actor can indistinctly play the role of representer or interpreter. As a representer, the actor is capable of creating a representation for a domain object (e.g. the child observes his father and he represents him as a stick figure). As an interpreter, the actor is capable of interpreting a representation and evoking the domain object. The conception is the thought that is formed in the mind of the actor during the process of conceptualisation (e.g. the mental figure of the father in the mind of the child). The conception is the mental substitute of the domain object and it appears both while perceiving the domain object and while perceiving the representation. Conceptions play a major role in the framework. As a result of communication and shared understanding, conceptions become social constructs and as such can well be used as a basis of a conceptual framework [Braun, Hesse et al. 2000]. In order to avoid circular definitions, FRISCO starts from a set of assumptions. These assumptions are terms with a meaning that is taken for granted and they are part of a widely shared natural language. The set of a priori assumptions is a basic ontology. Examples of such terms are "world", "human being", "perception", "mind", "conception", "pattern", "time", "process" etc. The FRISCO framework is structured in five layers [Falkenberg, Hesse et al. 1998].

1. The Fundamental Layer. The fundamental layer is based on the ontological assumptions that any parts of the world may be conceived as a thing or as consisting of things, and that there may be changes. It defines concepts such as Thing, Relationship, Predicator, Predicated thing, Composite thing, Transition, Transition occurrence, Relative time, etc.

2. The Layer of Actors, Actions, and Actands. In many cases of discussing information system issues, it is useful not only to talk in terms of things, relationships, states and transitions, but also in terms of actions, actors and actands. The latter concepts can be defined in terms of the former ones. It defines concepts such as Actor, Action, Actand, Resource, Goal, etc. Also, this layer defines relations (functions) such as Actorof, Inputof and Outputof.

3. The Layer of Cognitive and Semiotic Concepts. This layer specialises concepts from the previous layer. The aim is to define cognitive and semiotic concepts which are relevant for explaining the "semiotic tetrahedron" and the process of modelling. It defines concepts such as Human actor, Domain, Perception, Perceiver, Conception, Conceiver, Interpreting action, Interpreter, Representation, Language, Representing action, Representer, Model, Model denotation, Message transfer, Message, Communication, etc. Figure 14 shows the sequence of interpreting and representing actions performed by a human actor.

4. The Layer of System Concepts. This layer defines the general notion of system and some related concepts. FRISCO considers the system to be a model of a domain where all the elements are interrelated such that they form a coherent whole. A system is conceived to have at least one emergent systemic property. It defines concepts such as System, Sub-system, Dynamic System, Static system, Active system, Passive system, Active system, Passive system, etc.

5. The Layer of Organisational and Information System Concepts. This layer deals with the notions of organisational system (which is considered to be an open, dynamic and active system). Organisational systems


39

contain actors, actions and actands, and the relationships among these elements. Also, they have the systemic property that its actors are pursuing at least one specific organisational goal. It defines concepts such as Organisational system, Knowledge/data-processing action, Information system, Computerised actor, Computerised information sub-system, etc.

Figure 14. Interpreting and representing actions, performed by a human actor (from

[Falkenberg, Hesse et al. 1998]) 13

The FRISCO approach will be addressed with more detail in the following sections. Appendix E summarises the concepts defined by the FRISCO report.

3.4. Comparison of approaches: my own epistemological stance

Comparison of formal and social approaches is inevitably biased by the epistemological stance adopted by the one who performs the comparison. In the following, several points of view on the matter are compiled and confronted to my own opinion. Wand and Weber consider that an IS is essentially a representation of real world phenomena [Wand and Weber 1995]. It may appear as if they arrive to this conclusion due to their way of working; that is, to their systematic search for sound foundations for the Information Systems discipline. It may appear as if they actually identify the conceptual core they are searching for just in the middle of the ISs discipline. In my opinion, however, their conclusion is the result of their own intention, of their bias. Weber makes explicit their strong will [Weber 1999]. He asks himself whether we need disciplinary foundations for the ISs discipline. Evidently yes; without foundations there is no soundness. I find this as clear-cut as he does. Probably no researcher can argue that those foundations are not necessary. The issue is whether those foundations pertain to the IS discipline or they can be borrowed from other disciplines. He sees some inconvenience in belonging to a discipline that does not claim ownership of any foundational

13 Actors, actions and actands are represented by triangles, squares and circles, respectively.


40

knowledge. His line of argument is summarised in Table 1. His “strong preference is to belong to a discipline that owns its foundational knowledge” [Weber 1999]14.

A discipline borrows foundations from other disciplines

A discipline owns its foundations

“They must be forever be attuned to those disciplines that inform their work.”

The discipline is fully independent.

“They must add value through the innovative and effective application of multiple foundational knowledge bases to a problem.”

“Their focus will be the ongoing articulation of the owned knowledge.”

“The essence of these disciplines is synthesis.”

“Their identity will be formed not in the synthesis of other disciplines’ foundational knowledge but in the substance of their own foundational knowledge.”

“Their value-adding contribution is to show how knowledge from multiple disciplines can be used in an integrated way to solve complex problems.”

“The discipline will stand or fall on the value ascribed to this foundational knowledge.”

“In my view, disciplines that do not own their foundational knowledge tend to be ephemeral. They can be subsumed by the disciplines that provide the foundational knowledge as the members of these disciplines seek to expand the range of phenomena that they study.” “Over the long run, I believe that disciplines that do not own their foundational knowledge tend to fragment and dissipate.” “They sometimes feel acutely the vagaries of change.” “They do not endure.”

Disciplines that own their foundational knowledge are long-lasting. These disciplines do not fragment, nor dissipate. They endure.

“As a matter of personal taste, I find that knowledge within disciplines that rely on synthesis often is not pleasing aesthetically.” “My experience is that the knowledge that is their focus frequently is superficial and uninteresting.” “It is dominated by the application of theories from other disciplines or research results that manifest sometimes mundane (and even ill-informed) tests of theories from other disciplines.” “When theories do emerge, they lack elegance and rigour.” “They tend to be a hodgepodge of theories from other disciplines.”

Knowledge within disciplines that own their foundations is pleasing aesthetically. These disciplines focus on deep and interesting knowledge. They apply their own theories; when new theories do emerge, they are elegant and rigorous.

14 Sentences in brackets are explicit comments from Weber, the rest is an interpretation of his opinion. I may be wrong in my comparison.


41

“Disciplines that do not own their foundational knowledge are exposed politically. My experience is that they have difficulty commanding the respect of scholars in other disciplines, and thus they frequently lose fights over the allocation of resources. Moreover, they often become a target for takeover by other disciplines when resources begin to flow to them because the phenomena they study suddenly become important practically.”

Disciplines that own their foundational knowledge are not so exposed politically. Their scholars are respectable and they don’t usually lose fights over the allocation of resources.

Table 1. Weber’s opinion on the need of belonging to a discipline that owns its foundational knowledge.

These (prejudiced) statements show an intention that guides his reasoning and the quest for a conceptual core for the ISs discipline. In order to identify the discipline core he proposes to “strip away all the phenomena that are the focus of theories from other disciplines and to determine whether any phenomena remain.” He strips away layers as if the discipline were an onion, pulling the petals off the daisy flower. “We were left with the phenomena that is variously called conceptual modelling, semantic modelling, and data modelling. Only here could we find phenomena where the primary theoretical bases had been developed within the information systems and computer science disciplines rather than other disciplines.” [Weber 1999]. What remains at the end is “that one set of core phenomena within the information systems discipline pertained to the notion that information systems were a representation of some real-world phenomena” [Wand and Weber 1995]. Their rigour is praiseworthy and it contributes his work with a stony soundness. However, to the best of my knowledge, they have built a wall that protects an erroneous conception of Information Systems. This conception is erroneous in the sense that it is partial and fragmented. An IS is something more than a mere representation of the real world: it is a support for the communications of an organisation. The representation of the real world is only a means to achieve the communicational end; that is, the representation is just the memory of the IS. I do not doubt that the representation of the real world be part of the discipline’s core foundation. I agree with that point. I just believe that it is a mistake to think that we only have to build upon the foundational core. In my opinion, Weber et al. are wrong when they decide to dissect the knowledge that our discipline owns and make it grow separately. Without the knowledge owned by the related disciplines, the conceptual framework goes lame. The emergent properties that arise when all the components of an Information System are considered together are lost if we focus on only one component. It is often speculated that common-sense realist approaches (such as Chisholm’s ontology) are useful with regard to domains where social and human aspects are crucial; this is the case of Information Systems from a broad perspective. On the other hand, formal scientific-realist approaches (such as Bunge’s ontology) suit better those domains where social and human aspects are absent implementation; this is the case of implementation domains. [Milton and Kazmierczak 1999]


42

My opinion is even more biased towards the social aspects. An ontology that attempts to comprise the concepts underlying Information Systems comprehension and development, needs to take into account the many social issues that are present in ISs; e.g. communication, Pragmatics, Semiotics, etc. See the following quote from Lyytinen. Although it does not explicitly address Bunge’s ontology, it reflects a point of view on the matter.

“Formalistic information models have limitations, however. They disregard the characteristics of the users and the uses of data and their impact [Stamper 1985]. Although information models attempt to capture the meaning of data, they are inadequate in this task because they are based on a too naive theory of meaning [Winograd and Flores 1987]. In effect, information models have a bias toward treating “meaning” as a stable and immutable entity originating from outside human judgment [Kent 1978]. This bias can increase bureaucratic side effects and introduce dysfunctions in the information systems’ processes [Lyytinen 1987b] [Stamper 1986].”

From [Lyytinen 1987a]. For purpose of creating a generic model of Information Systems (a conceptual framework), this work takes the FRISCO approach as a starting point for several reasons. We share the constructivist and semiotic stance with the authors of FRISCO. We also believe that an interdisciplinary approach to Information Systems research is necessary. FRISCO authors have emphasised the importance of a sound and consistent foundation of the IS field. Among other issues, such a foundation requires some deeper investigation of its relations to underlying and neighbour disciplines such as philosophy, mathematics/computer science, linguistics and social science [Hesse and Verrijn-Stuart 2000]. The FRISCO report goes beyond the common narrow view of information systems as pure technical artefacts by adopting an interdisciplinary, socio-technical view on them [Hesse and Verrijn-Stuart 2000].


43

4. On the evaluation and comparison of modelling techniques and software development methods

When it comes to evaluating and comparing modelling techniques and software development methods, one comes across several problems. First of all, methods are loosely defined, often based on common sense and intuition. Also, there is a lack of widely-used standard techniques for evaluating methods. Different approaches to comparing methods are possible. Siau and Rossi made a comprehensive review on the matter [Siau and Rossi 1998]. The authors distinguish between empirical (see Table 2) and non-empirical (see Table 3) method evaluation techniques. Non-empirical evaluation techniques Technique Description Strengths Weaknesses Feature comparison.

It consists of studying how different methods tackle the same problem (how they model the same domain). Then a checklist of ideal method features is developed. The checklist is used to evaluate methods.

Relatively easy to perform if the criteria are well defined.

Subjectivity in the development of checklists. Subjectivity in the evaluation of methods.

Meta-modelling

It consists of using a common metamodelling language for method comparison, so as to map methods to some "super-method", or compare models of methods by identifying their common parts.

The technique is said to be more objective than feature comparison

Still some degree of subjectivity in metamodel creation and in evaluation

Metrics approach

Aimed at analyzing the complexity-based features of methods by means of metrics. This approach analyzes a formal method metamodel and computes metric values that can be compared to reference values.

Metrics can provide a valuable aid for method comparison.

A lot of empirical work is needed to validate the metrics.

Paradigmatic analyses

Analyses assumptions behind systems development. The approaches that are “emancipatory” or “intersubjective” are seen categorically superior to technical and individual approaches.

Could be valuable aids in selecting a method for use within an organisation.

Might not be directly applicable for end users.

Contingency identification

Provides heuristics for minimizing risks and identifying the problems which we try to address with the methods.

Rule-of-thumbs can be of great help for practitioners. Could satisfy the needs of the researchers and at the same time aid the practitioners

There is a need for triangulation, which combines approaches in a way suitable for contingencies of the situation at hand.

Ontological evaluation

The basic idea is to evaluate the constructs in existing methods by matching them with ontological constructs. Typically based on a modification and extension of the ontology developed by Bunge.

It is at least derived from a strong theoretical foundation.

The question of why Bunge’s Ontology was chosen has always been raised.


44

Approaches based on cognitive psychology

The use of cognitive psychology theories as the basis for evaluating modelling methods.

These theories are usually well developed and tested in their respective disciplines.

Choosing the right theories from the right disciplines to apply is no easy task.

Table 2. Survey of non-empirical method evaluation techniques (summarised from [Siau and Rossi 1998])

Empirical evaluation techniques Technique Description Strengths Weaknesses Survey Survey gathers data on attitudes,

opinions, impressions, and beliefs of human subjects via questionnaires. This technique allows testing of a priori hypotheses and offers an iterative approach to the generation of hypotheses.

Method adoption is said to be based on their perceived usefulness. Suitable for geographically dispersed practitioners

Low response rate from the recipients of the questionnaires (30-40%) Subjectivity of perception.

Laboratory experiment

The researcher manipulates the independent variables (e.g., different modelling methods, different constructs) and measures the effect of the independent variables on the dependent variables (e.g., accuracy of modelling, accuracy of interpretation, confidence level, time taken).

Ability to control intervening and confounding variables. Internal validity is its biggest strength.

Artificiality of the research settings (e.g. simplicity of the experimental task) limits the external validity of the results.

Field experiment

Field experiment takes place in a “natural setting.” The researcher manipulates the independent variables and at the same time trying to control the most important intervening variables The researcher then measures the effects of the independent variables on the dependent variables by systematic observation of human subjects.

Overcomes the artificiality of laboratory experiments.

Field experiment is more difficult to conduct than laboratory experiment. Gaining access to organisations is not easy (reluctance).

Case study A particular subject or organisation using one or more modelling methods is observed by the researcher without intervening in any way. No independent variables are manipulated, no control is exercised over intervening variables and no dependent variables are measured. The case study attempts to capture and communicate the reality of a particular environment at a point in time.

Organisations are less reluctant that to experiments. Triangulation is an approach to partly overcome subjectivity involved. The richness of the data in case study is something that survey and experimentation cannot match.

Subjectivity of the researcher’s interpretation. The research site is rarely randomly selected. The observation is usually interpreted by the researchers alone (or in small group).

Action research

Action research allows the researcher to become a part of the research. The objective with this approach is not the finite testing of a particular hypothesis but the realization of the “human creative potential.” This approach allows the researchers to

This approach can provide detailed analysis and insight into the modelling methods that are very difficult to

Interpretation is subjective. The effect of the researcher involvement in the modelling process is also a


45

take part in the modelling process (usually as consultants) and report their experience.

capture otherwise. problem.

Table 3. Survey of empirical method evaluation techniques (summarised from [Siau and Rossi 1998]

The reviewed approaches have strengths and weaknesses. All of them are useful when trying to evaluate software development methods and techniques. This work focuses on ontological approaches. This role of ontologies in the field of Computer Science is identified by Barchini et al as a support for conceptual analysis of methods and techniques oriented to ISs development [Barchini, Álvarez et al. 2007] (see page 33). In the literature, ontological evaluation is also referred to as ontological analysis. In Section IV.3 a procedure for ontological evaluation is proposed; it is referred to as conceptual alignment. Ontological evaluation requires the definition of reference ontology and the definition of a procedure to perform the evaluation of a software development method.

4.1. Ontological evaluation of software development methods

In Section 3 the use of ontologies in the area of Computer Science has been reviewed. Two kinds of approaches have been distinguished: formal scientific realist approaches, common-sense realist approaches and constructivist approaches. Mario Bunge is a representative author of formal scientific realist approaches. Roderick M. Chisholm is a representative author of common-sense realist approaches. The FRISCO report is a representative constructivist approach. Both formal scientific realist and common-sense realist approaches have been used for the ontological evaluation of software development methods, focusing on modelling techniques15.

Figure 15. General procedure for ontological evaluation of modelling techniques.

In general, the evaluation procedure consists of mapping ontological concepts and modelling primitives and then considering that those modelling techniques that

15 There is no evidence that constructivist approaches have been used for the ontological evaluation of software development methods.


46

cover the ontological concepts are better than those modelling techniques that do not cover the ontological concepts. This way, in the example shown in Figure 15, modelling technique A covers two ontological concepts, whereas modelling technique B covers three ontological concepts. Therefore, modelling primitive B would be considered better than modelling primitive A. Obviously, actual procedures for ontological evaluation of modelling techniques are more complex and their outcomes are more detailed. In [Wand and Weber 1990; Wand, Monarchi et al. 1995; Weber 1997; Weber 1999] the authors proposed the use of ontological concepts to evaluate information modelling methods. The basic idea is to evaluate the constructs (primitives)16 of existing methods by matching them with ontological constructs (concepts)17. To do that, they take and extend Bunge’s ontology and they apply it to the modelling of ISs. Their main contribution is to have adapted and used Bunge’s ontology to study ISs design and development tools. The formal, abstract model introduced by them is called Bunge-Wand-Weber (BWW model), which is a model with an interesting amount of works around all these ideas. They introduced the notions of construct overload, construct redundancy, construct excess, and construct deficit [Wand and Weber 1993]. These notions are exemplified in Figure 16.

Figure 16. Exemplification of the ontological evaluation of a modelling technique (a.k.a.

modelling construct)

• Construct overload. A conceptual modelling grammar allows one modelling primitive to be used to represent more than one ontological concept.

• Construct redundancy. A conceptual modelling grammar allows one ontological concept to be represented by more than one modelling primitive.

• Construct excess. A conceptual modelling grammar has a modelling primitive that has no real-world counterpart; that is, it matches no ontological concept.

16 In this work, the term modelling primitive is used instead of modelling construct. 17 In this work, ontological constructs are referred to as ontology elements or ontological concepts. In Section IV, the ontological concepts of the ISs conceptual framework are referred to as elements of the generic IS model.


47

• Construct deficit. An ontological concept does not have any corresponding modelling primitive.

Opdahl and Henderson Sellers have used the BWW ontological model to carry out the ontological evaluation of several object-oriented modelling languages [Opdahl and Henderson-Sellers 1999]. The outcomes of their evaluation have resulted in the definition, integration and formalisation of modelling techniques. UML (Unified Modeling Language) has been evaluated [Opdahl and Henderson-Sellers 2002]. OML (Open Modelling Language) has been evaluated [Opdahl, Henderson-Sellers et al. 2000] and its metamodel has been revised [Opdahl and Henderson-Sellers 2001]. Also, the whole-part relationship has been analysed and clarified [Opdahl, Henderson-Sellers et al. 2001]. The work of Wand and Weber is based on structural comparison of elements of grammar and concludes only presence or absence of a modelling primitive [Milton and Kazmierczak 2004]. The conclusions drawn are very much based upon whether or not the data modelling language supports the ontological concept. Milton, Kazmierczak and Keen have developed a method for the ontological analysis of modelling languages that is based on Chisholm’s ontology [Milton, Kazmierczak et al. 2001]. Their work seeks to develop semantic methods that not only detect the presence or absence of a modelling primitive but also allow the researcher to judge the level of agreement or disagreement between a data modelling language and a reference ontology. They define the goal of the ontological evaluation as comparing the ontology embodied in a data modelling language with the reference ontology selected from the range of ontologies available [Milton and Kazmierczak 2004]. This method is depicted graphically in Figure 17.

Figure 17. Method of ontological evaluation of modelling techniques (method of conceptual evaluation) [Milton and Kazmierczak 2004]

The researcher takes as input the reference ontology (in their case, Chisholm’s ontology) and the ontology underlying a given modelling technique18. The output of the ontological evaluation is a list of similarities and differences between the two sets of concepts and a qualitative analysis of those similarities and differences. “It is not necessary for either the ontology or the data modelling language to be

18 In the name they give to this element (Data model ontology) one can perceive their bias towards a data-centred view of Information Systems. The same happens with BWW-related works. The communicational perspective is not given the importance it deserves.


48

described using a mathematical formalism. It is possible that both are at best semi formal with natural language descriptions of concepts found in each.” [Milton and Kazmierczak 2004]. Basically, the ontological evaluation consists of four basic steps:

1. Determine the set of concepts from the reference ontology to be used in a forward evaluation. This set of concepts is referred to as reference concepts.

2. Determine the set of concepts from the ontology embodied in the data modelling language to be used in a backward evaluation. This set of concepts is referred to as data modelling concepts.

3. Perform a forward and backward evaluation of the two sets of concepts and tabulate the results.

4. Perform the analysis step in which the results are analysed. By carrying out the ontological evaluation to several modelling techniques, using the same reference ontology, the researcher can compare the modelling techniques. The authors took five standard modelling techniques and evaluated them with respect to Chisholm’s ontological concepts: Entity-Relationship, Functional Data Model (FDM), Semantic Data Model (SDM), NIAM, and Object Modelling Technique (OMT). Figure shows a concise report of the ontological evaluation.

Figure 18. Results of the comparison of several modelling techniques using Chisholm’s

ontology (from [Milton and Kazmierczak 2004])


49

5. Conclusions on the review of related works

In Section II.3, works related to Information Systems generic models (ontologies, conceptual frameworks) have been reviewed. We distinguished formal scientific-realist approaches, common-sense realist approaches and constructivist approaches. Also, their use for the evaluation and comparison of ISs modelling techniques has been reviewed. Note that there is no evidence that a constructivist approach has been used as a reference ontology in an ontological evaluation of software development methods. We claim that the use of ontologies is just a need for accomplishing rigorously the development of Information Systems. Independently of the chosen definition, behind an ontology we have a process of conceptualisation and we believe conceptualisation is the most important component of any software production process in the IS arena. We need precise concepts to understand which are the basic building blocks of the different models that compose a given software production method, and how they combine correctly. Accepting that we need those concepts, we are strongly demanding to understand which ontology underlies a particular approach. If we do not have such an ontology, we simply cannot compare, understand and evaluate the different components of those software production methods. However, one should be careful when building an ontology or extending an existing one. As argued in [Herrera, Pallioto et al. 2005], critics of the BWW model make two types of claims. On the one hand, the models are difficult to understand. This lack of understandability hinders their use for evaluating grammars (modelling languages). On the other hand, there is a lack of socio-cultural aspects in the model. IS are considered merely technological systems and not socio-technical systems inserted in an Organisational System. This is the challenge that we want to face in this work. Starting from what we consider a sound definition of a framework of Information System concepts –the FRISCO report [Falkenberg, Hesse et al. 1998]-, we fix our basic ontology for ISs development by enriching the initial framework with some new, required concepts. Many of the IS elements (ontological concepts) that are considered in this proposal are not addressed by previous proposals. Also, we share the constructivist position adopted by the authors of FRISCO and, furthermore, we place emphasis on the human and sociological aspects of Information Systems (e.g. communication).

III. A generic model of Information Systems

51

III. A GENERIC MODEL OF INFORMATION SYSTEMS


52


53

1. Introduction

As stated by Mylopoulos in [Mylopoulos 1998], the use of conceptual models for Information Systems (ISs) engineering was launched by Sølvberg in [Sølvberg 1980] and comprehensively represented in Bubenko’s Conceptual Information Model [Bubenko 1980]. A reasonable degree of maturity of the use of these models was attained during the 80's. The FRISCO reports are a good reflection of this. If a framework for ISs is required, the FRISCO proposal [Falkenberg, Hesse et al. 1998] is, in our opinion, a very appropriate starting point. We propose to establish a framework of well-defined and related concepts in order to reason unambiguously about Information Systems. Instead of starting from scratch, we build this conceptual framework based on the FRISCO report. However, the ISO report of 1987 is a previous proposal which is worth taking into consideration [ISO 1987]. In the following the ISO report of 1987 is referred to as ISO82.

Figure 19. FRISCO report front page


54

2. From ISO87 to FRISCO: it is all about communication

In the 80’s, an ISO report [ISO 1987] presented a conceptual framework for Information Systems, defining the basic interaction architecture shown in Figure 20. According to this report, every Information System (IS) reacts to messages depending on different objectives. The objective of the IS is to memorise reported facts. The main objective of the organisational System (OS) is to react to events19.

Figure 20. Information System model according to ISO87 [ISO 1987]

When it comes to comparing ISO87 and FRISCO IS models, two issues should be addressed with respect to the ISO87 diagram (see Figure 20).

• Intention. ISO87 distinguishes between ingoing messages, which are intended to enter new information that the IS was not aware of, and outgoing messages, which are intended to recover information from the IS memory.

• Communication. Although bidirectionality is not explicitly drawn, ingoing and outgoing messages are, in actual fact, input and output dialogs, respectively. However, these dialogs are asymmetric (see Figure 21). This is quite clear in the case of output dialogs: the objective of a listing is to retrieve facts from the system memory, but some information input may be needed (e.g. report parameters such as selection criteria). In general, this input information is only used to generate the output, so it is not expected to be stored persistently.

Figure 21. ISO87 IS model adapted to show communicative bidirectionality

FRISCO does not maintain this view; the report presents a slightly different diagrammatic view of the IS, by focusing on the dialogical communication between the IS and its users. The input and output dialogs of ISO87 are generalised. Figure 22 shows the FRISCO conception of the IS as a “channel for the message

19 The authors of ISO87 acknowledge that they adopt a naive realist approach to Information Systems.


55

transfers between the various users” who want to “communicate about one and the same domain”. FRISCO contributed an essential a foundation stone on the subject of Information Systems. In the midst of terminological fuzziness, FRISCO adopted a constructivist philosophical position and proposed a set of definitions that addresses the underlying concepts behind any IS from various semiotic angles. FRISCO modelled the dialog occurring in an interaction. In the FRISCO model of the IS (see Figure 22), users are actors that specify input messages to the processor and receive output messages from it. Processors are actors that are responsible for checking input messages, keeping the domain model denotation (i.e. the information base) logically consistent with the language representation (i.e. the conceptual model), and retrieving information to produce output messages; in short, a processor is responsible for the IS reaction to external stimuli.

Figure 22. Model of a generic Information System according to FRISCO

FRISCO description of the interaction between the users and the IS is a refinement of each of two dialogs defined by ISO87. There is an implicit asynchrony between the ISO87 input and output dialogs, while in the FRISCO diagram the interaction loop occurs synchronously. In summary, the diagrammatic view of an IS in ISO87 is projected in a forked fashion onto the FRISCO diagram (see Figure 23).

Figure 23. Projections of the ISO model onto to the FRISCO model


56

3. Definitions borrowed from FRISCO

The framework that we propose in this work is based on the FRISCO conceptual framework [Falkenberg, Hesse et al. 1998]. First, we present several definitions directly from the FRISCO report. In subsequent sections, some of the concepts are extended and specialised to achieve a better understanding of the complexity of Information Systems. Relevant concepts come in bold. For the sake of brevity, we do not include here some basic assumptions and the definition of concepts of the fundamental layer (e.g. thing, relationship). These definitions can be found in the FRISCO report and also in Appendix E. A transition is a special binary relationship between a pre-state and a post-state, where both states are composite things that differ in at least one thing. A transition occurrence is a specific occurrence of a transition. A set of transition occurrences is subject to strict partial ordering. Usually it is said that a transition occurs at a certain point in time. Let the strict partial order (<) imposed on the set of all transition occurrences be called relative time. The absolute time, which consists of time points, can be derived from the strict order of clock transition occurrences. Through the predicators before and after, relative time is introduced. An action is a transition involving a non-empty set of actors in its pre-state, and, if not “destroyed” or “consumed” by the action, in its post-state as well, and involving a nonempty or empty set of other things (actands) as part of its pre-state, and having a nonempty or empty set of other things (actands) in its post-state. An actor is a special thing conceived as being “responsible” or “responsive” and as being able to “cause” transitions. Let actorOf be a function determining the actors performing an action. A human actor is a responsible actor with the capabilities and liabilities of a normal human being, in particular capable of performing perceiving actions, conceiving actions and representing actions. In turn, a non-human actor is any actor that is not human (e.g. sensors and other Computerised Information System components such as a central processing unit). An actand is a thing involved in the pre-state or post-state of an action, not considered as an actor for that action. An input actand or output actand is a part of the pre-state or post-state of an action, excluding the actors. The pre-state of an action (the union of the set of actors and the set of input actands) is called its resources. Let inputOf be a function determining the input actands of an action. Let outputOf be a function determining the output actands of an action. The goal of an action is a special input actand of that action, pursued by the actors of that action and stating the desired output state intensionally. A message is an actand composed of data, transmitted by one actor (the sender) via a channel (a medium), and intended for a non-empty set of other actors (the receivers). It is important to note that, in this work, although a message transfer is a complex sequence of actions (see Figure 4), we sometimes abstract some of its steps for the sake of simplicity.


57

4. Notation

The FRISCO report proposed a concise graphical notation for the main types of elements and their relationships. This notation is shown in Figure 24.a and is intensively used throughout this work.

Figure 24. Notations employed for the Information System models

In addition to the symbols for actors, actions, actands and their relationships, we use a basic abstraction mechanism that is not addressed by FRISCO notation. Some IS elements are generalised by placing them inside rectangles; these rectangles are marked by an icon that denotes the kind of elements it generalises (see Figure 24.b). This syntactical resource is used for the sake of “diagrammatic economy”, which we believe implies greater cognitive simplicity. Note that the diagrams shown in Figure 24.c and Figure 24.d show two actions (A1 and A2) and two actands (N1 and N2). In Figure 24.c, the actand N2 is an input of both actions. In Figure 24.d, the actions A1 and A2 have been generalised and the inputOf relationship between the actand N2 and the generalisation keeps the same semantics as in the diagram in Figure 24.c: the actand N2 is still an input for both actions. Sometimes, the generalisation rectangle also helps to identify the refinement of a concept from a previous model. Nevertheless, we include a symbol to explicitly denote aggregation (see Figure 25).


58

Figure 25. Notation for the heterogeneous aggregation

Topologic inclusion is reused (see the notation for generalisation in Figure 24) but now more than one icon appears in the bottom-right side of the rectangle. These icons denote the types of elements being aggregated. A diagrammatic interface for FRISCO concepts has been proposed [Wohed and Andersson 2005]. This interface represents FRISCO concepts by means of a UML class diagram. At the beginning, we used this type of representation for our extension of the FRISCO model of an IS. Some of the early generic IS models were built in terms of a UML class diagram (see Appendix A). However, we then chose to remain faithful to the graphical notation proposed by FRISCO because we feel that, this way, the IS model is easier to grasp.


59

5. A generic model of Information Systems

We distinguish between external and internal actions. External actions are those that occur outside the boundaries of the IS. The change that some external actions induce in the state of the Subject System is of great interest to the Organisational System. We refer to these external action occurrences as events. The term event requires clarification since it has been overloaded with different meanings by different authors.

• In the literature on real-time, embedded, and control systems, the concept of event is often used in a broad sense (disregarding whether the transition occurrence is external or internal to the system).

• In programming environments, the term event designates any stimulus that interrupts a system component activity.

• The same happens in object-oriented analysis and design techniques. For example, an individual stimulus from one object to another is an event for [Rumbaugh, Blaha et al. 1991]. Also, “in the context of state machine, an event is an occurrence of a stimulus that can trigger a state transition” [Booch, Rumbaugh et al. 1999].

• However, we use the term event in a way similar to [ISO 1987] and [Falkenberg, Hesse et al. 1998]. In the context of our work, an event is a stimulus that occurs in the outside world and to which the Organisational System must respond [Yourdon 1989].

An external message is a message that is involved in a message transfer in which either the sender is communicating an event to the IS (e.g. a hotel clerk checking out a customer, a sensor informing that the temperature has risen above a safe level) or the IS is communicating facts upon petition of an actor belonging to the Organisational or Subject Systems (e.g. a hotel director consulting the results of the last summer season). Figure 26 shows an event occurring in the domain of the Subject System. An actor perceives this occurrence and reports it to the Information System. It is called Primary actor in the sense that this actor “owns” the information that is being communicated to the IS; he/she is the ultimate source of information and communicative intention. This actor can belong to the Organisational System (as the diagram suggests) or not. The reaction of the Organisational System to the event may have connative influence on the Subject System. In other words, the OS may induce changes or trigger some reaction on the Subject System. However, in this work, we preferred not to close the loop. Both the Input and the Output messages are considered to be external messages.


60

Figure 26. Subject domain events trigger organisational response

This figure makes use of the FRISCO notation for actors, actions and actands (see Figure 24). We extend the FRISCO notation with the use of rounded rectangles (like the ones used in Figure 3) to denote the boundaries of the different systems involved20. In Section 7, the issue of boundaries is discussed, as well as the fact that the Primary actor may or may not belong to the Organisational System. In the diagram, heterogeneous aggregation is used to denote a clustering of concepts. Note that, since the event is a transition occurrence, it has no symbol assigned to it. The event is, therefore, represented as an action that is performed by an actor of the Subject System, which is perceived as being of interest to the OS. The FRISCO report [Falkenberg, Hesse et al. 1998] defines the following external functions of the Organisational System: impression is the “conception of changes in the system domain as caused by the environment”, and expression is the “conception of changes in the domain of the environment as caused by the system”. Figure 26 extends the FRISCO model (see Figure 22) by taking into account what happens outside the boundaries of the IS. Now, the focus is placed on what happens inside the Information System. The IS, strictly speaking, can be further decomposed by refining the IS processor and its actions. This is done in Figure 27; the following variations have been made to achieve this diagram. The interactive loop has been individualised to fit a single Subject System event reaction. Therefore, many elements are now named in singular terms (although they can still be considered as the class of the things they denote); i.e., the Users actor has been renamed Primary actor (as in Figure 26). The Actions of the processor

20 Instead of rounded rectangles, an aggregation of actors, actions and actands (conforming to the notation in Figure 25) would be more rigorous. However, we decided to use rounded rectangles to keep diagrams simple and because the boundaries of the systems are just tentative.


61

element has been refined inside the bigger box (which is also used as a generalisation of actions) and the Processor itself has been specialised.

INFORMATION SYSTEM

Formulation of input

message

Input message

Information System reaction

Information base

entity(ies)

Edition and encoding of input

message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message

Interpreta-tion of output

message

Conceptual schema

Primary actor

Decoding and display

of output message

Figure 27. First refinement or the generic Information System model21

The rest of this section is structured in five subsections in order to explain how Figure 22 has been refined to achieve Figure 27. The names of the IS elements are printed in italics. When the IS elements are defined, they appear in bold font.

5.1. The Information System Memory

The Language representation is equivalent to the ISO82 Conceptual schema of the IS and, therefore, this element has been renamed. The Conceptual schema gathers the abstract knowledge of the Organisational System: the model of the IS memory, the types of facts the IS can register, and many rules about its behaviour. The Domain model denotation is equivalent to the ISO82 Information base, which is mainly composed of Information base entities. Entities and their relationships are the IS memory imprints about Subject System facts. The Conceptual schema and the Information base entities are input for all the actions generalised inside the box.

5.2. Envisioning the Interface as a Message Editor

The IS Processor is refined into Interface processor and Reaction processor. The Actions of the processor has been decomposed into three actions: Encoding and decoding of input message, Decoding and display of output message, and Information System reaction. The Interface Processor actor is in charge of editing

21 Note that one actorOf relationship crosses an action for the sake of a nicer layout.


62

messages in the interface of the IS. The Formulation of the input message corresponds to the formulation of a fact that has occurred and has been perceived in the Subject System; this action produces the Input message, which the Primary actor expresses in terms of the subject domain language (e.g. a verbal utterance). The Edition and encoding of input message is the process of re-encoding the Input message into a Coded input message so that the IS accepts (understands) it and is able to react according to the type of message. This translation is intended to re-express the message using a shared linguistic code [Jakobson 1990] (see Section II.1) that is closer to the solution (e.g. a form provided by the organisation). This view enforces the conception of the IS interface as a message editor. However, the interface is also a message displayer, if the opposite direction is considered. A Coded output message, which is originated by the IS reaction, needs to be translated again to an external actor-intelligible Output message and issued to the actor by means of a Decoding and display of output messages action. Note that both actions of the interface can make use of the information base (e.g. to help the user pick a business object without having to know its internal identifier).

5.3. The Information System Reaction

The Reaction processor performs the following steps of the Information System reaction: 1) It takes the Coded input message and checks whether it corresponds to one of

the expected types of messages (this knowledge is contained in the Conceptual schema).

2) Then, it takes the needed facts from the information base. 3) It processes all this information according to a certain recipe of rules (i.e. an

algorithm). 4) It updates the knowledge of the OS (information base). 5) It produces one or several Coded output messages showing the result of its

actions and conveys them to the actors concerned. Obviously, the Information System reaction could be further refined to explicitly denote all these steps, but we chose to keep the diagrams simple. This issue will be addressed by future works.

5.4. The Organisational System Reaction

The Organisational System (OS) reacts to Subject System events according to certain Organisational Goals, which are usually stated by organisational actors at the strategic level. Goals affect actions and can, therefore, be considered as input actands. Figure 28 shows a broad generalisation of the organisational actions that are affected by Organisational Goals. Goals should be considered as the conceptual schema of an organisation. A particular subset of these goals is Information System Goals, which affects the IS actions.


63

SUBJECT SYSTEM

ORGANISATIONAL SYSTEM INFORMATION SYSTEM


message

Input message


message



message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Conceptual schema

Primary actor

Event actor

External action

considered interesting

event

Perceptible result of the

event

Interpreta-tion of the

event

Interpreta-tion of IS reaction

Organiza-tional

reaction to the event

Information base

entity(ies)

OS’s perceptible reaction to

event

Perception and interpre-tation of the

event

Organisational goals

Information System goals

Figure 28. Second refinement of the generic Information System model

We acknowledge that the reality22 is much more complex than the model proposed in this work. However, this simple model will allow us to begin understanding reality better.

22 The term ‘reality’ should be taken from a Constructivist philosophical position.


64

6. The IS interface viewed as a message editor (and displayer)

The communicational nature of Information Systems (IS) is always present in all its descriptions. IS are viewed as a collection of artefacts of different nature that collaborate to support the communication between an Organisational System (OS) and its environment and within the OS itself [Lockemann and Mayr 1986]. An IS is basically a collector-distributor of messages. The natural, systemic way of analyzing the IS is to study its interface. It is through the interface of the IS that interactions occur. The interface is essentially the responsible for exchanging of messages between the IS and its environment. The communicative point of view can be further developed by focusing on:

• The supporting agents; that is, the process of actually transmitting a message (the work of Shannon addresses supporting agents [Shannon 1948]).

• The meaning of the messages as formulated by the sender and construed by the receiver (the work of Jakobson addresses meaning and shared knowledge [Jakobson 1990]).

Notice that, in both views, a message is considered to be a thing that is already built. In the case of transmission-oriented perspectives, the emphasis is on the conveyance of an already-given message. In the case of meaning-oriented perspectives, the approach is more semiotic, but it is also interested in the interpretation of an already-built message. Even the FRISCO report, which is influenced by both perspectives, does not discuss the message building phase. FRISCO conceives the interaction with the IS as a three-step procedure: (1) a message (formulated by the user) is received, (2) the IS verifies that the message is correct and (3) the IS reacts accordingly (see Figure 22). In order to gain a more profound understanding of what happens on the interface of the IS, we have analysed the message building phase. The message building phase is the process of producing a description of reality that can be properly understood by the IS. This phase is mainly influenced by the goals of the Primary actor (the user); however, the IS also influences the process by placing restrictions on the editing and encoding of the message. The reactive phase is mainly influenced by the goals of the IS which, in turn, depend on the goals of the OS. The building phase requires the creation and location of an editorial environment. Each communication is associated to a specific editorial environment. The editorial environment is a collection of things that collaborate to support the building of a message. The editorial environment is related to the shared knowledge and shared code that is needed for a communicative act (see Figure 5). The editorial environment is composed of metalinguistic context (form) and linguistic context (content). Metalinguistic context is related to the form and structure of the message, while linguistic context is related to the factual information that is involved in the editing and encoding of the input message. When actors want to communicate something to the system, they first have to locate the editorial environment that will aid them in building the message.


65

Location allows dealing with the cardinal complexity of the types of interactions. The higher the number of interactions types the IS permits, the more necessary it is to offer support to the location of their corresponding editorial environments.

Figure 29. Refinement of the IS reaction to address context recovery

Figure 29 shows the extension of the generic IS model shown in Figure 28. Even though it does not explicitly address the location of the editorial environment, it does address the recovery of the context. We clarify these concepts with the following example. An example of a non-computerised (part of an) Information System has been chosen in order to demonstrate that the concepts we are defining are independent of computerisation; that is, these concepts are applicable to Information Systems independently of whether they have been automated or not. A customer arrives at the insurance agency. He wants to file a claim. He approaches the receptionist’s desk and asks for advice. The receptionist asks him what kind of claim he wishes to file and the customer mentions that he has had a car accident. The receptionist sends the customer to an office where the clerk who is in charge of auto insurance will attend to him. This is an example of an editorial environment location. In this case, the location is dependent on the organisational responsibilities (e.g. go to that counter for car claims). The clerk asks the customer whether the accident involves damage to his car or it is a liability claim by a third party. This is another example of an editorial environment location. Since the claim is for damage to his car, the employee gives the customer form F178, which the customer must complete. The form is part of the Metalinguistic context recovery. The form is a very prescriptive structure for the message being communicated. It is not common to allow a free editing of the message as in narrative, hand-written letters (or text processor, in computerised IS). It is customary to abide by a fixed form, which is part of the OS Conceptual schema. The form is composed of several fields, which can include the following: the customer’s name, the names and addresses of all persons involved, the hour, date, place and facts of the accident, and the names and addresses of witnesses. The


66

format of the fields is also related to the metalinguistic context; for example, the customer has to adhere to the date endianness suggested in the form (mm/dd/yyyy). Also, any recommendation in the construction of the message is an expression of metalinguistic context. For example, the form requests the customer to limit the description of the accident to 50 and 100 words. However, as the customer is not sure of what he should explain, he asks the clerk for help. The customer is acting as the Primary actor (he owns the information being reported) and also as the Interface processor (he is filling the form himself and, therefore, he is editing the message). The clerk acts as a Reaction processor who is aiding the customer to build the message by recovering knowledge from the Conceptual schema of the OS. Therefore, the clerk offers the customer a better explanation of how to describe the accident. The clerk also carries out a Linguistic context recovery from the Information base. When the customer gives the clerk his insurance policy number, the clerk checks the IS memory and gives some feedback (e.g. “Mr. Smith, right? Your policy covers the following…”). The domains for the different fields are also part of the linguistic context. For example, the expected values for the zip code are part of the factual knowledge. When the customer has completed his form, the clerk skims through the form. The clerk points out that the vehicle plate number is missing and hands it back to the customer. Error messages giving feedback about the input message construction are also part of the metalinguistic context.

Figure 30. How editorial facilities make message editing easier

In many Information Systems, the message building phase is complex. The Interface processor needs some aid to reduce the complexity. These complexity reduction aids are sometimes offered in the form of editorial facilities that deal with cardinality reduction and structural organisation.

• By cardinality reduction we mean to deal with the quantitative aspect of complexity. An example of an editorial facility that helps to reduce cardinality is a filter. When a salesperson provides a customer with the information about the gadgets available for the customer’s mobile phone, the salesperson is filtering most of the products in the shop just to offer the customer with those in which the customer is potentially interested. The


67

salesman is facilitating the selection of an instance (the selected gadget type) by reducing the linguistic context.

• By structural organisation we mean to deal with the qualitative aspect of complexity. An example of an editorial facility that helps to reduce the complexity by organising the linguistic context is an ordering facility. Ordering a set of facts following a given criterion makes easier the Interface processor task of discriminating between the facts (e.g. locating the instance that s/he needs).

To summarise, when an event of interest occurs in the Subject System, someone communicates it to the IS. The process of building the message that reports this occurrence is a complex mixture of actions. These actions involve the participation of both the Interface processor and the Reaction processor. In order to build the message, some contextual information needs to be recovered. The metalinguistic context mainly refers to the structure of the message, the format of its fields, any kind of aid in the editing and encoding of the input message, and error messages. The linguistic context refers to the domains of data fields and the factual feedback. Figure 28 shows the resulting generic IS model.

Figure 31. Extended generic Information System model


68

7. Acknowledgement of some limitations of the conceptual framework

Whenever one undertakes the modelling of any aspect of an IS, granularity emerges as an unavoidable issue to be tackled. Actions in general and organisational reactions in particular are susceptible to being treated at various granularity levels. The models presented in Figures 27 and 28 are focused on interactions between an actor and the IS at the refinement level (granularity) of Subject System events. A so-called business activity could comprise several of these interactions, or even be decomposed into much lower granularity interactions. We have tiptoed round this thorny issue in Section III, since it deserves to be tackled with great care and detail. We will argue about refinement and decomposition in Section IV.2. As said above, reality is always more complex than the models presented in this work. For example, goals often appear in complex structures as discussed at the beginning of Section II.1. Even within departments of the same OS, goals can be contradictory; the sales department and the accounting department can have different opinions about some issues that concern both departments. Organisational goals might not be shared by all the members of the OS; the personal goals of an operational actor are not necessarily consistent with the strategic goals (this is shown in Figure 32). When it comes to interactions in which two actors of different systems participate (for example, Subject System vs. Organisational System), goal conflicts can be worse. For instance, a customer (of an insurance company) has his/her own goals (to be indemnified for an illness), which may or may not coincide with the organisational goals (to pay the less money the better).

Figure 32. An example of different goals conditioning an actor23

23 In this figure, the types of actors correspond to the levels of an Organisational System (OS): strategic level concerns guiding and managing the OS, operational level concerns tasks related to daily operation.


69

Also, we acknowledge that our conceptual framework deals with goals from a very operational perspective. It is hard to argue that goals are input of actions (as the rest of resources are). In any case, it suits our purpose to model goals this way, in order to keep the framework and the notation simple. More complex conceptions of goals and intentionality can be found in the literature. For instance, Mallea and Knobeb reveal the underlying orderliness of people’s conceptions of intentions and intentionality [Mallea and Knobeb 1997]. They identify five factors upon which people judge intentionality; namely, desire, belief, intention, awareness and skill. Another issue in our conceptual framework is that, in real organisations, the boundaries may or may not coincide with the ones shown in Figures 26, 27 and 28. This is due to the fact that roles such as the Event actor, Primary actor and Interface actor may be played by the same or different persons, who in turn may belong to the OS or the Subject System. An example is an insurance claim:

• A customer has an accident (Event actor). The customer phones the insurance company and reports the accident (Primary actor). The clerk enters the information in the IS (Interface processor). In this case, the customer performs two roles.

• The customer can also opt to use the electronic form that the company has on its website to file a claim. In this case, the customer performs all three roles

• Later, the insurance agent issues an order for an expert appraisal of the accident. In this case, the insurance agent performs the three roles.

Therefore, the boundaries of the OS and the IS in Figures 26, 27 and 28 are just approximate. We also acknowledge that editorial environment location is not represented in our generic IS model, although it is part and parcel of any external interaction with the IS. The contextual recovery does indeed represent the creation and operation of an editorial environment, but the generic IS model has no element that represents the location of that particular editorial environment. Nevertheless, the concept of location has been defined and is part of the conceptual framework. We have given a definition of each new ontological concept. This is convenient in order to facilitate the understanding of our conceptual framework. Furthermore, we have represented the generic ISs model graphically, using the notation proposed by FRISCO. This has resulted in a set of figures that illustrate the relations among ontological concepts. However, we have not specified the concepts using a mathematical language. We acknowledge that this lack of formalisation can hinder the acceptance of the conceptual framework by the Ontology community.

IV. Understanding how Information Systems are described

71

IV. UNDERSTANDING HOW INFORMATION SYSTEMS ARE

DESCRIBED


72

1. Discovery and description of reality

In the area of Software Engineering and Requirements Engineering the following terms (and their derivations) are frequently used:

• Specify (i.e. software application specification) • Elicit24 (i.e. requirements elicitation) • Capture (i.e. requirements capture) • Model (i.e. model of the system, conceptual model) • Discover (i.e. requirements discovery) • Gather (i.e. knowledge gathering)

Even though many times these terms are used indistinctly, they do not all mean the same. We could try to describe them properly and see the relations among them. However, we opt to describe our conception and to define the terms we will use throughout this work. We will refer to the process of incrementing knowledge as knowledge capture. If the knowledge being captured takes the form of requirements for an Information System, then we will refer to this activity as requirements capture. In this work, this activity is also referred to as requirements elicitation.

Capture knowledge Human

being

Perceivable facts

Captured facts

Figure 33. A simplified view on the process of capturing knowledge

24 Spanish and Latin American readers should have in mind the following entry from the Diccionario Panhispánico de Dudas REA (2005). Diccionario panhispánico de dudas, Real Academia Española.; this entry states that the English verb elicit has given rise to an incorrect Spanish term: elicitar. Adaptación innecesaria del verbo inglés to elicit, que aparece a veces en textos de psicología con el sentido que corresponde a los verbos españoles provocar, suscitar u obtener, según los casos: «Tuvimos éxito con el procedimiento de elicitar discusiones maritales reales y lograr el interés de las parejas en la conversación» (Psicología [Chile] 2002); «Información elicitada de los estudiantes en vez de administrada a los mismos» (Becoña/Palomares/García Tabaco [Esp. 1994]); en el primer caso debió decirse provocar o suscitar discusiones y, en el segundo, información obtenida.


73

Figure 33 shows that a human being captures knowledge by perceiving facts of its environment. This is a simplified view of a much more complex behaviour in which many perceptual and cognitive processes are involved. For instance, Figure 34 shows a refinement of Figure 33 in which some of these processes are depicted graphically. When we are open to the surrounding environment, we come across things that produce stimuli that reach us. Properly speaking the stimuli reach our sense organs (e.g. light reaching our eyes, sonic air waves reaching our ears). Sense organs transform these stimuli into sensations that are conveyed through our nerves towards the brain. In the brain, a perceptual process takes place and sensations are transformed into perceptions. Perceptions are interpreted according to personal knowledge (e.g. previous experiences), so interpretations now increase our personal knowledge. Sometimes the result of this process fuels our curiosity and we seek new things in the environment, therefore closing the loop. Whenever we try to describe our personal knowledge, we chose some modelling language and we produce a description (e.g. we draw a diagram). If we want to share our knowledge with others, then we need to use common codes that are shared with the recipients of our description.

Personal knowledge

SensationSenseThings we

find or come across

Perceive

PerceptionInterpreteInterpreta-tion

Describe

Seek new things

Common codes

Discovery

Description

Description

Human being

Figure 34. A more detailed view on the process of capturing knowledge

For the purpose of clarifying our terminology, we define two main processes. Capturing knowledge usually consists of discovering and describing facts:

• Knowledge discovery. The process of observing the world (sensing-perceiving-interpreting-seeking) in order to increase our knowledge.

• Knowledge description. The process of describing previously captured knowledge using a shared code.


74

2. On perspectives and decompositions

Software methods propose techniques that, in turn, propose modelling languages. Each modelling language has a reduced set of concepts and some syntactic patterns to perceive and describe reality. These languages produce descriptions that are related to each other in two ways. The descriptions have horizontal relations since they depict complementary aspects of reality, i.e., they give us different perspectives of reality. They have vertical relations since they give us different degrees of detail about reality. The refinement into a deeper level of detail is called decomposition. These horizontal and vertical abstraction mechanisms are often combined to describe reality. In the following, some concepts related to perspectives and decomposition are defined.

2.1. Perspectives

We use the term perspective to refer to the way aspects of reality are projected using a syntactic pattern of concepts. Perspectives are usually referred to as models or descriptions. Each perspective describes reality by means of a series of modelling primitives used as a filter to see reality (see Figure 35). These modelling primitives can be mapped to the elements of the Information System framework.

Figure 35. Perspective patterns act as a lens through which we see reality

We consider these modelling primitives to be a pattern. We use the term perspective pattern to refer to the concepts and syntactic patterns that are used to obtain a certain description of reality. For instance, a perspective pattern can be an ontological view derived from the proposed conceptual framework (the ISs ontology). Also, modelling techniques are sometimes described by means of metamodels; these metamodels are a form of perspective pattern.


75

2.2. Decompositions and localised decompositions

Decomposition is a useful abstraction mechanism that produces different levels of detail of a system. Each level is obtained by refinement, using a given perspective pattern. Figure 36 shows the decomposition of an element of a description. In this example, a different perspective pattern is used to build each description. E.g. this is the case when a use case is decomposed by creating an activity diagram. However, sometimes the same perspective pattern is used. E.g. this is the case when a process of a data flow diagram (DFD) is refined in a lower-level DFD.

Figure 36. Decomposition establishes a vertical relationship between descriptions of the

same system

The classical view on refinement is to describe components in terms of an aggregation of lower level components. However, an increase in detail is not the only intention of refinement. Another intention could be location. Components are located in space or in space-time. Any capsule is a container. Its components can be considered from a spatial point of view. When there is only one dimension, the spatial view does not seem relevant. Vertical relationships among descriptions are mereological but can also be mereotopological. Topological inclusion should not be confused with mereology [Winston, Chaffin et al. 1987]. Topological aspects in software descriptions were outlined by [Wieringa 1998]. Wieringa stresses the difference between communications and behaviour. “Communications are the way functions are ordered in space [whereas] behaviour is the way in which functions are ordered in time. Taking the grand view, the distinction between communication and behaviour is similar to the distinction between space and time.” Space and time are very basic concepts in ontology. In Sowa’s ontology the basic categories Abstract and Physical are defined on the basis of space and time predicates [Sowa 2000]. Thus, he considers space and time to be pre-eminent concepts. All ontologies distinguish the category of things that extend over time and the things that do not. In BFO [Grenon 2003], basic categories include Endurant and Perdurant entities. Endurant entities do not have time extension. Endurant25 entities can be substances, places and dependent entities like conditions, qualities or functions. “Places are endurant entities which are co-located with substances, their fiat-parts and aggregates”. Perdurants26 are entities that have temporal parts 25 Endurant is a universal that has also been called Continuant. 26 Perdurant is a universal that has also been called Occurrent.


76

and that happen, unfold or develop in time. In OpenCyc the SpatialThings object is the collection of all things that have a spatial extent or location that is relative to some other SpatialThing. SpatialThings are not necessarily tangible. “A SpatialThing might or might not be located in the actual physical universe” [OpenCYC 2007]. This line of argument can be usefully applied to better understand how refinement is used with the intention of locating things. Some components that are used in software descriptions can be related to other components in a spatial or spatiotemporal way. In past methods, processing environments were already considered as encapsulating criteria. Actors and other forms of organisational arrangements were used as spatial containers of functions. For instance, functional refinements or WBS were spatial decompositions of functions. Structured techniques also used this kind of spatial decomposition based on organisational units. The introduction of object orientation brought another spatial consideration that former proposals could not deal with. Object orientation gave de possibility of arranging methods or interactions in the objects space. In our model, actors and classes (actands) are considered as spatial things. Functions, scripts, events and other perdurant components (actions) can be associated to spatial things. We refer to a refinement in a perspective that locates parts in space or in space and time as localised decomposition. When the temporal dimension is considered in a decomposition, it may be reflected in an absolute way (with respect to a certain agreed scale; e.g. Gregorian calendar and UTC) or by means of relative time relationships (e.g. before, after, precedence). For example, activity diagrams are localised decompositions of functions (Figure 37 shows an activity diagram using the FRISCO notation for actors and actions). The spatial dimension, which is the set of actors involved, is deployed on the horizontal axis. The time dimension, which is reinforced by precedence relationships among activities, is deployed in the vertical axis. As a whole, localised decompositions describe a functional aggregate that pursues a given goal. Each activity is located in space and time.

Figure 37. Activity diagram as an example of localised decomposition

In summary, we decompose on a given perspective or, conversely, we project a perspective at a given level of decomposition detail. Sometimes decompositions can be localised decompositions.


77

3. Conceptual alignment of software development methods

The conceptual alignment of a given method is the establishment of mappings between the elements of the ISs ontology and the modelling primitives of the modelling languages proposed by the method. The modelling primitives of a modelling language can be conceptually aligned either to the ISs ontology (ISs conceptual framework) or to an ontological view (perspective pattern). Conceptual alignment is a procedure for ontological evaluation of software development methods, as explained in Section II.4.1. When carrying out the conceptual alignment of the modelling techniques proposed by a given method, some IS elements27 may not be mapped to the modelling primitives. Some types of IS elements are omitted while the IS is being described, this is referred to as ellipsis. It is a temporary ellipsis when a given element is omitted at a given instant in order to focus on other elements that are associated to it, using the transitivity property. It is a total ellipsis when the given method definitely omits a particular IS element. In this case, the question arises as to whether or not the method would benefit from considering that type of element in its descriptions of the Information System. The concept of total ellipsis is similar to the Wand and Weber’s concept of construct deficiency. Figure 38 shows an organisation of the concepts presented in this section. The concepts are organised on the abstraction layers proposed by [OMG 2006]28.

(INFORMATION SYSTEMS) ONTOLOGY

ONTOLOGICAL VIEWS

TECHNIQUES

DESCRIPTIONS

INSTANCES

M2 LAYER

M1 LAYER

M0 LAYER

Perspective patternEllipsis

Modelling languages (primitives)Localised decompositionsMethods

Models (case study)Perspectives

Con

cept

ual a

lignm

ent

Conceptual framework

Figure 38. Overview of the discussed concepts

27 By IS elements we refer to elements of the generic IS model; that is, ontological concepts. 28 We acknowledge that this organisation on the OMG layers is arguable. The figure considers the IS conceptual framework (ontology) to be a metamodel. This is done for clarification purposes and it may change in future work.


78

4. Practical application of conceptual alignment

The conceptual framework introduced in Section III can be used to show the reasoning principles that are behind any specific software development method, independently of its core paradigm. As a practical example, we are going to apply the concepts to explain the following software development methods:

• The Rational Unified Process (RUP) [Rational 2003] • The Wisdom method [Nunes and Cunha 2000] • The OO-Method [Pastor, Gómez et al. 2001]

With regard to the way of presenting the conceptual alignments, we considered several techniques that would allow us to specify and illustrate them. Even though we created a meta-model using a UML class diagram [OMG 2005c] and started to define OCL expressions [OMG 2003b] to navigate through the meta-model, we soon realised that the FRISCO notation for the IS elements was more appropriate since it is visually intuitive and less demanding from a cognitive point of view. The purpose of this work is to analyze and obtain deeper knowledge about the concepts behind software production methods. We aspire to reason and, if possible, help other practitioners reason about the methods they use or propose. However, we do not seek to establish an ontological domain that holds as a universal reference. This is why we ruled out the specification of conceptual alignments in a more formal way. We expect to use our framework to support a series of methodological research lines. According to McGuinness’ characterisation of ontologies, our conceptual framework should be taken as a “simple ontology” [McGuinness 2003] addressing basic concepts (their definitions and relations). The same strategy is followed at each step: a graph of elements of the IS generic model is displayed. This graph is an ontological view of the generic IS model. Then, the relevant elements are “coloured” depending on the specification activity or technique that it is being considered. Also, the mappings between IS elements and modelling primitives are traced. For the sake of understandability, it is important to select an appropriate notation. The notation that is used contains the following primitives (see Figure 39):

• Elements that are currently being specified at a certain step. A thick-lined shape with background represents an IS element that is being described at that very step.

• Elements that have not yet been specified. These are denoted by a soft grey line and font. When an undescribed element appears between elements currently being described, this is a case of ellipsis. For instance, ellipses commonly occur between actors and actions of the IS when applying use-case modelling techniques.

• Elements that have already been specified. A normal dark-lined shape with background represents IS elements that have been specified in previous steps and that are not relevant in the current specification step.

• A thick, dashed arrow represents the mapping between specific elements of the framework of reference (or a generalisation of elements of the same type, or a heterogeneous aggregation) and specific modelling primitives of the given technique.


79

• Heterogeneous aggregation allows us to map several elements of distinct types to one modelling primitive. In Figure 39.b, one modelling primitive is aligned to two ontological elements. In Figure 39.c, the modelling primitive is aligned to a heterogeneous aggregation of two ontological elements. Both ways of tracing the mappings specify the same alignment; it is a question of nuance.

Figure 39. Notation for the conceptual alignment

This notation is applied to the conceptual alignment of the OO-Method conceptual-modelling phase and to the higher-level modelling techniques proposed by the RUP and to some of the modelling techniques recommended in Wisdom. It must be clarified that, in order to show the conceptual alignment of the software development methods and, at the same time, exemplify its proposed techniques with a case study, we have used descriptions instead of modelling-language definitions. That way, when we trace mappings between an element of the generic IS model (ontological concept) and an element of a description, we are implicitly tracing the mapping between the concept and the modelling primitive used to express that element of the description. The reader needs to do a little effort in order to classify the elements of the description, but we are killing two birds with one stone.


80

5. The Rational Unified Process

5.1. RUP at a glance

The Rational Unified Process (RUP) is a software engineering process that provides a disciplined approach to software development by defining responsibilities, tasks and artifacts to be created. The RUP is a commercial product developed and marketed by Rational Rose, an IBM company. It defines four phases (Inception, Elaboration, Construction and Transition) which are enacted by means of iteratively working on different disciplines (Business Modelling, Requirements, Analysis, Design and Implementation among others). Each discipline is described in terms of workflows (a temporal ordering of groups of activities), roles (a way of classifying stakeholders depending on their responsibilities), activities (a unit of work a role may be asked to perform) and artifacts (modelling primitives and documents that activities produce, evolve, maintain or use as input). The authors of RUP remark the following main characteristics [Kruchten 2003]:

• Use-Case driven. Use Cases are a requirements elicitation technique which allows the specification of fragments of system functionality that provide some value to the users. The RUP employs them not only as functional requirements capsules but also to drive the design, implementation and testing of the software application.

• Centred on architecture. The architecture of a system is a view of the organisation and structure of its most relevant parts, which involves both static and dynamic aspects of the system. It is related with how the system is to be built and in which order. Non functional requirements such as quality, performance and reuse need to be taken into account. The architecture is influenced by the chosen hardware and software platform, operating system, database management system, networking protocols, legacy systems to be interacted, etc.

• Iterative and incremental. The RUP proposes the division of work into manageable parts. Each iteration can be seen as a mini-development project where the main discipline workflows are enacted. This allows the Use Cases and the architecture to balance out progressively. According to [Jacobson, Booch et al. 1999], this balance is similar to the one between form and function in the development of the product.

The RUP recommends certain modelling techniques to build the artifacts; these are mainly based in the Unified Modeling Language (UML) [OMG 2005c], a general-purpose modelling language that includes a standardised graphical notation used to create abstract models of a (software) system. The RUP offers a wide range of modelling activities and techniques; it is intended to be tailored to suit the needs of a particular project. We will focus the conceptual alignment on the models that specify the Information System in a more abstract way. Whenever the RUP offers some leeway to interpret the concepts behind a modelling primitive, we have reduced the degree of freedom in order to map the primitive to an ontological concept.


81

Business Goal

Business Use-Case Model

Business Analysis Model

Business Actor

Business Use Case

Business Rule

Business Event

Business Use-Case Realization

Business Worker

Business Entity

Business System

Use-Case Model

Use-Case Package

Use Case

Actor Storyboard

Analysis Model

Analysis Class

Boundary Class

Control Class

Entity Class

Design Model

Protocol Capsule Use-Case Realization

SignalEvent

Design Subsystem

Design Package

Interface Design Class Test

Design

Data Model User-Interface Prototype

Navigation Map

Testability Class

=

=

=

=

=

=

Figure 40. Overview of RUP models and their primitives

Figure 40 shows an overview of the models proposed by the RUP. Also, the modelling primitives that correspond to each model are shown between brackets. Boxes with grey background specify which (parts of) the models are conceptually aligned in the following section.


82

5.2. Conceptual alignment of the high abstraction models of the RUP

According to the notation at the beginning of Section IV.4, we develop next the conceptual alignment of some of the modelling techniques the RUP recommends in order to describe the Information System and its computerisation. To exemplify the modelling techniques we adapted the Wiley College case study29, which specifies the development of a student registration system. The resulting client-server application should allow professors to access the system in order to sign up to teach courses as well as to record students’ grades. Students should be able to register for courses and view report cards. The modelling primitives of the proposed techniques are underlined when they are discussed for the first time. The elements of the reference IS model are printed in italics.

5.2.1. Business Use Case Model

Modelling the business helps to understand current problems in the Organisational System (OS) and to identify potential improvements, assessing the impact of organisational change. It also contributes to establishing a common understanding of the OS; customers, end users, analysts, developers, and other stakeholders should agree on a shared view of the business. The RUP proposes several artifacts to be produced in order to model the business. We focus on the Business Use Case Model and the Business Analysis Model. The Business Use Case Model is a model of the business goals and intended functions. This model helps to identify roles and deliverables in the OS. First, business goals need to be identified, defining what needs to be achieved in order for the OS to reach the desired competitive position. They correspond to the Organisational goals ontological concept, a subset of which is the Information system goals. This is why this actand is represented with a thick line and coloured background (see Figure 41). These goals may be decomposed and structured so each lower-level business goal can be traced back to the higher level goals it supports. Also, assigning metrics to goals enables to measure the achievement of business goals. Moreover, we need to find business actors, which are not to be considered as individuals but represent a role played in relation to the OS by someone in the Subject System (e.g. customers, partners and suppliers). By considering what value each business actor receives from the business, business use cases can be found and related to them. A business use case represents a specific workflow in the OS “that yields an observable result of value to a particular business actor [Rational 2003]. While business actors map to Primary actors, business use cases are the abstraction of a sequence of actions that a business performs and therefore they are a mixture of actions within the OS; this is represented by mapping them with a generalisation of actions. 29 IBM offers the Wiley College case study as an example of a tailoring of the RUP. We have adapted the case study when necessary. More info can be found in http://www-128.ibm.com/developerworks/rational/library/4315.html


83


message

Input message


message



message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Primary actor


event


Organisa-tional


Information base

entity(ies)


event

Reliable, high quality course registration system

Usability Process efficiency

Security

Student

Consult Grades

Solicit Revalidation

Register for Courses



Figure 41. Specifying business goals, actors and use cases in the Business Use Case

Model

5.2.2. Business Analysis Model

The business use cases specified in the previous step present an external view of the business by focusing on the interaction between the OS and its environment. On its turn, the Business Analysis Model gives an internal view of the business use case by analyzing what tasks are carried out inside the OS in order to achieve the desired results. The RUP calls this internal view a business use case realization; it describes the business use case in terms of business workers and business entities. The use case realization can be refined by means of an activity diagram or a sequence diagram. Figure 42 shows an example of an activity diagram that refines the realization of the Solicit Revalidation business use case; a student who has taken courses in a foreign college can request their recognition. The activities are laid out on lanes, depending on the business worker that carries them out. These activities correspond to any of the actions of the IS model, as well as business workers correspond to any of the actor roles:


84

• A business worker will act as an Interface processor whenever s/he is just transducing the message formulated by the business actor. For instance, a clerk entering the order of a client is mainly performing the Edition and encoding of input messages (the client is actually the Primary actor).

• A business worker will also act as a Primary actor in the cases where s/he is providing new information to the IS, as a result of its responsibilities within the OS. For instance, when a salesman scans through the list of orders and identifies the pending one a Perception and interpretation of (a past) event is taking place. After taking some time to decide s/he goes on to the Formulation of input message and communicates to the IS the decision to accept the order and to send it to production.


message

Input message


message



message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Primary actor


event


Organisa-tional


Information base

entity(ies)


event

Student ProfessorInternational

Relations Subdirector

Solicit revalidation of course

Analyse petition

Make decision

Inform refusal Update certificates

Inform acceptance

Request documentation to original college

[Refuse] [Accept]



Figure 42. Refining a use-case realization in the Business Analysis Model


85

So an activity diagram can be used to refine some dynamic or functional component. It depicts participations, as defined by Sowa. Participations are physical-relative-ocurrents [Sowa 2000]. Participations can be seen as a physical representation of histories. Each part of the representation is bounded in space and time. Each part is co-located with an actor and occurs in some point of time.

ProfessorSchedule

Course Offering

Course


message

Input message


message



message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Primary actor


event


Organisa-tional


Information base

entity(ies)


event

International Relationships Subdirector

Revalidation Petition



Figure 43. Defining business workers and entities in the Business Analysis Model

The activities in which a business use case realization is refined affect business entities. A business entity represents “a significant and persistent piece of information that is manipulated by business actors and business workers” [Rational 2003]. Business entities are a primitive version of the Information base entities. At this step of requirements elicitation only a few entities of this type will come up during the interviews, those that are more relevant to the OS. The RUP proposes another view of the Business Analysis Model where the relations among business workers and business entities are specified (see Figure 43). As mentioned above, business workers are mapped to a generalisation of the three actor roles.


86

A third view of the Business Analysis Model partitions the IS in several business systems with an organic criteria. A business system “encapsulates roles” (business workers, Actors) “and resources” (business entities, Information base entities) “that together fulfil a specific purpose” (Organisational goal) “and define a set of responsibilities with which that purpose can be achieved” [Rational 2003]. The business system is equivalent to a subsystem of the IS and, therefore, it corresponds to a heterogeneous aggregation of many of its elements.


message

Input message


Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Primary actor


event


Organisa-tional


Information base

entity(ies)


event

International Relationships Office

Revalidationsmanagement

Manage grants

Teaching staff

Administration

ExaminationLectures

Accounting


message

Internal procedures management

Data maintenance



Figure 44. Defining a view of the business systems in the Business Analysis Model

Following our approach, the Business Analysis Model view of business systems localises aggregated functions in the organisational space. The model (see Figure 44) defines different functional responsibilities and assigns them to organisational units (business systems). Each organisational unit (e.g. Administration) offers an interface that contains one or several aggregated services (e.g. data maintenance, accounting, and internal procedures management). These aggregated services are groups of interactions. In this case, the relationships that are established among organisational units by means of the usage of services correspond to the mediating category of Sowa’s work [Sowa 2000]. In other words, the relationships among organisational units are not of type indexation or participation; they describe a composition of the “thirdness” grade which, as Pierce stated, necessarily requires a ternary expressivity: consumer, service and producer [Peirce 1998]. Since the


87

interfaces are aggregations of services, we have mapped them to the Formulation of input messages and the Interpretation of output messages. No actual message is specified in the Business Analysis Model.

5.2.3. Use-Case Model

The Use-Case Model specifies the Computerised Information System functions and its relation with the users. This model is composed of actors (also referred by the RUP as system actors to acknowledge the fact that they interact with the IS) and use cases (the capsule of functionality that will guide the rest of the software development process).




message

Input message


message



message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Primary actor


event


Organisa-tional


Information base

entity(ies)


event

View Report Card

User

Student RegistrarProfessor

Login

Register for Courses

Select Courses to Teach

Submit Grades

Maintain Student Information

Maintain Professor Information

Close RegistrationRequestRevalidation

Figure 45. Defining actors and use cases in the Use Case Model


88

The Business Analysis model already identified those Actors that belong to the OS and take part in the realization of business use cases. Now, an actor of the system is defined for each business worker who will use the Computerised IS. In the case study, the professor will use the system to select the courses s/he is going to teach and to submit the student grades. Also, we may decide that some business actors are going to interact with the IS. This is the case of the students, who will interact with the system to register for the offered courses, to request the revalidation of a course, and to view the report card at the end of the semester. Business workers will not become system actors if the processes they take part of are not going to be computerised (only the request is computerised). This is the case of the International Relationships Subdirector; Wiley College decided not to automate the management of course revalidations. Additionally, some additional actors of the system may appear at this step, typically those of the administrator type (e.g. the registrar). Since system actors define “a coherent set of roles that users of the system can play when interacting with it” [Rational 2003], they correspond to Interface processors that will communicate messages with the IS. In any case, they also may be playing the role of Primary actors if they provide the new information to the IS. Use cases are an abstraction of actions performed within the IS. They define the scope of the software implementation, since only the functionality they define will be computerised. The perspective pattern of use cases shows an ellipsis of some communicational elements. The Primary actor is assigned an aggregate function of the IS, but that relation overlooks the Input message and the Output message. The relationship between a system actor and a use case is purely a trigger that only takes into account the phatic function of communication (the contact) [Jakobson 1990]. Even when use cases are refined by means of use case descriptions or scenarios (a description of the sequence of actions done to carry out the use case), the message that is specified (if any) is the Coded input message (expressed in terms of the application interface).

5.2.4. Analysis Model

Just as the Business Analysis Model described the realization of business use cases, the Analysis Model is an object model describing the realization of use cases in terms of analysis classes. Analysis classes may be of three different kinds:

• Boundary classes act as an interface to actors outside the IS, whether they are human (then they model the user interface), devices (then they model peripheral device/sensor drivers) or other systems (then they model the communication with computerised systems that fall off the scope of the project). Conceptually, all three uses of the boundary classes model the Edition and encoding of input message and Decoding and display of output message, independently of whether the actor is a sensor, a human or a whole integrated subsystem.

• Control classes model control behaviour concerning one or several use cases. These classes correspond to an encapsulation of the Information System reaction.

• Entity classes model the IS memory; they represent the information that needs to be stored persistently to keep track of changes in the Subject


89

System and the Organisational System. However, since these classes also model behaviour associated to these pieces of information, they are mapped to a heterogeneous aggregation of Information base entity (the static view of the class) and Information System reaction (its dynamic view).

Figure 46 shows this alignment. Note that, for the sake of simplicity, only one of the analysis classes (the Course Offering) has been expanded to see its attributes and methods.

Schedule


message

Input message


message



message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Information base

entity(ies)

Course Catalog System

Registration Controller

Student

Course OfferingcoNum: String

startTime: TimeendTime: Time

days: EnumnumStudents: Intadd_professor()add_student()

remove_student()get_num_students()close_registration()

Close Registration Controller

Billing System

Professor

Course

Register ForCourses Form

Primary actor



Figure 46. Specifying the memory and the reaction of the system in the Analysis Model

The RUP continues with the specification of the Design Model, in which the system is further refined in terms of the chosen platform and programming language. Then the implementation is carried out, obtaining the final software application. Many other models support the rest of the process (e.g. architectural decisions, testing,


90

deployment and process management) but we have restricted the conceptual alignment to those with higher abstraction. With respect to the specification of the interface the RUP proposes the use of storyboards, navigation maps and the design of user-interface prototypes. The design of storyboards aims to “explore, understand and reason about the behavioural requirements of the system” [Rational 2003]. Storyboards can describe nearly any aspect of computer-human interaction. Storyboards can represent actions the user can take, or requests the user can make on the system; information that is shown to, or entered by, the user. Also, storyboards can adopt nearly any form, from paper sketches to screen shots. With this looseness, a rigorous conceptual alignment of storyboards is not feasible. The navigation map is said to express “the structure of the user-interface elements in the system, along with their potential navigation pathways” [Rational 2003]. However, little methodological guidance is offered and no specific notation (thus, no modelling primitives) is defined for this model: one could use a hierarchical tree diagram, free-form graphics or a UML class diagram to represent navigational maps. Navigation is related to localisation of editorial environments but no rigorous conceptual alignment is possible. A user-interface prototype is an example of the user interface that is implemented to explore and/or validate the user-interface design. The RUP provides no modelling primitives for prototyping so, again, no conceptual alignment is possible.


91

6. The WISDOM method

6.1. Wisdom at a glance

Whitewater Interactive System Development with Object Models (Wisdom) [Nunes and Cunha 2000] is a UML-based software development method; therefore, it is object-oriented. It is said to be lightweight since it can be learnt and put into practice in a relatively short time, and it was designed to fit the production procedures of small software development companies. The proposal consists of an evolutionary and use case-based method; the project is iteratively developed in a sequence of incremental prototypes until the final product is obtained. The development process is driven by Use Cases, which serve the purpose of analyzing the system at a high abstraction level. “In Wisdom they [use cases] also serve as the major input for finding and specifying task flows, analysis classes and interaction classes. In addition, they work as containers for non-functional requirements.” [Nunes and Cunha 2001].

Figure 47. Model architecture in the Wisdom method, extracted from [Nunes and Cunha

2001]

Four workflows (definitions of development phases) are proposed: Requirements, Analysis, Design and Evolution workflows; see the models that correspond to these workflows in Figure 47. The implementation phase is done by manual programming. The first work sessions with users are intended to carry out an analysis of the business objects and processes, to identify user profiles, and to compile generic requirements. Without going into how the requirements are elicited (e.g. using post-it notes as in [Dayton, Kramer et al. 1996]), they are described in terms of stereotype-extended UML diagrams. System interactions are specified as use cases and are extended with activity diagrams whenever they are composed of many tasks. This will facilitate the specification of the interface in abstract terms, without giving specific platform-dependent details. Wisdom proposes the use of


92

interaction spaces, which are a modelling primitive that specify the structure of the interface. The Wisdom model architecture ranges from high-level models that are used to describe requirements to low-level implementation models that precisely specify the software application to be built. The method places emphasis on the Information System interface description.

6.2. Conceptual alignment of some Wisdom models

Some models have been disregarded since their alignment was not feasible (e.g. Implementation Model). To exemplify the modelling techniques, we adapted a case study that was first introduced in a publication of the authors [Nunes, Toranzo et al. 1999] and used in subsequent Wisdom-related papers. Hotel guests make reservations with the hotel according to their preferences and the availability of rooms. When a guest arrives at the hotel, s/he is attended by the registration clerk, who will check the details provided by the guest with those already recorded. When a guest leaves the hotel, the clerk enters the details of the staying and prints a bill. The guest pays the bill, leaves the hotel and the room becomes available for a new guest.

Figure 48. Requirements workflow in Wisdom (from [Nunes 2001])


93

In the following, the modelling primitives of the proposed techniques are underlined when they are described for the first time. The elements of the generic IS model to which the modelling primitives are conceptually aligned are printed in italics.

6.2.1. Requirements Workflow

The Wisdom Requirements Workflow (see Figure 48) proposes two classical techniques for requirements discovery: the Domain Model and the Use-Case Model. Although Wisdom proposes the specification of non-functional requirements as annotations attached to the hierarchical level that suits them best [Nunes and Cunha 2001], we opted to keep the diagrams simple. The Domain Model captures relevant things that the OS is interested in by means of a class diagram [OMG 2005a]. These (business) classes correspond to the Information Base Entities ontological concepts.

0..*1

1..*1

Has1..*

1..*

Stays

HOTEL

RESERVATION BILL

CUSTOMER

ROOM


message

Input message


message


message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message

Output message


of output message


message

Primary actor

Meta-linguistic context

recovery

Information base update and reaction

feedback

Linguistic context

recovery

Information base

entity(ies)

1..*

1

Contains

Figure 49. Identifying the entities of the Domain Model

Figure 49 shows the mappings between the elements of the generic IS model and the elements of a description. As it has been explained in page 79, the mappings between the elements of the generic IS model and the modelling primitives are implicitly traced. The Use-Case Model describes a decomposition of actors that interact with the IS. The Wisdom use-cases approach is interaction-oriented. The system is decomposed into actors, each of which has their own interactions or use cases (see Figure 50). The set of interactions is isomorphic to the set of input messages. The use-case actor that triggers the use case is aligned to the Primary actor. In the hotel case study, the customer is the ultimate source and destination of information. The use case modelling primitive is aligned to a generalisation of IS


94

actions, because the use case is a mixture of actions within the IS that will be refined in later steps. The <<initiator>> relationship relates each use case with the use-case actor that triggers the interaction. Wisdom emphasises the initiator role of the primary actor. An ellipsis of the Input and Output messages occurs. Therefore, use cases emphasise the phatic function of the communication (contact) and obscure the cognitive function. Additional actors may specify Interface processors, those actors that support the encoding and decoding of messages; this is the case of the clerk, who acts as Shannon’s transmitters and receivers by physically interacting with the computerised IS.

<<initiator>>

<<initiator>>

Figure 50. Identifying IS interactions in the Use-Case Model

Each use case is refined using task flows. Wisdom uses activity diagrams [OMG 2005a] to detail essential use cases [Constantine and Lockwood 1999], expressing the desirable and realistic task flows. These task flows will guide the design process ensuring that the interaction model reflects the task steps as they are actually perceived by the users. Figure 51 shows the task flow corresponding to the “Make reservation” use case and the conceptual alignment of the modelling primitives.


95

Figure 51. Refining use cases by means of a task flow

Task flows depict the tasks associated to each interaction. A task flow specifies a spatiotemporal decomposition of a use case, where tasks are distributed according to actors and time. Actors are depicted as lanes where activities are spatially localised. A lane is established for each of the actors involved in the use case (see Figure 51). Therefore, the lanes are conceptually aligned to the Primary actor (the customer), the Interface processor (the clerk), and the Reaction processor (the system). The relative-time corresponds to the vertical axis, and relationships among the task steps represent precedence dependencies. Again, no communicative analysis is done and messages are ellipsed. Task steps localised in primary actor lanes are mainly aligned to a generalisation of actions of the type


96

Formulation of input message and Interpretation of output messages. The task steps that are localised in interface processor lanes are aligned to a generalisation of actions of the type Edition and encoding of input messages and Decoding and display of output messages. The task steps localised in system lanes are aligned to actions that deal with the Information System reaction. The Information System reaction is composed of the recovery of the editorial environment and the Information base update and reaction feedback. The recovery of the editorial environment includes Metalinguistic context recovery and Linguistic context recovery, which establish the shared codes and knowledge.

6.2.2. Analysis Workflow

The Analysis Workflow already shapes the internal view of the Computerised IS by refining and structuring the requirements described in the previous workflow. The Analysis Workflow produces the Analysis Model and the Interaction Model. Figure 52 shows the Analysis Workflow.

Figure 52. Analysis workflow in Wisdom (from [Nunes 2001])

The Analysis Model is a class diagram where analysis classes represent abstractions of domain concepts, focusing on functional requirements. Analysis classes are stereotyped following the same criteria as in the RUP [Rational 2003]: control classes model the behaviour concerning one or several use cases, and entity classes model the IS memory. However, in Wisdom, both of these classes have a static view and a dynamic view. Therefore, they are mapped to a heterogeneous aggregation of Information base entity and Information base update


97

and reaction feedback (see Figure 53). To keep the figure simple, analysis classes do not show attributes and methods.

Figure 53. The Analysis Model defines an initial architecture of the IS

The Analysis Workflow is completed with an Interaction Model. The Interaction Model drafts the architecture of the user interface. Two modelling primitives are used in this model: tasks and interaction spaces. These primitives are aligned later on, when the models of the Design Workflow are considered. The aim of the Interaction Model is to envision the design models that will specify the interface. Another aim of this model is to relate the internal and user-interface architectures to see how they collaborate in realizing the essential use-cases.

6.2.3. Design Workflow

The Design Workflow (see Figure 54) specifies the internal and external architectures of the IS in greater detail. In contrast to the Analysis Workflow, the Design Workflow also focuses on non-functional requirements and is platform-specific. An internal system design is achieved by means of a Design Model. This model refines the Analysis Model using relational schemas and taking the chosen programming platform into account. For reasons of brevity, this low abstraction level model is not aligned. The Design Workflow also produces two models that specify the user interface. Once the interaction style and the interface technology have been chosen, the Dialogue Model and the Presentation Model are built.


98

Figure 54. Design workflow in Wisdom (from [Nunes 2001])

The Dialogue Model refines the task steps of the task flow into a hierarchy of subtasks (vertical decomposition relationships). Tasks and subtasks are treated as stereotyped UML classes. Task classes are used to model the dialogue between the user and the system. Temporal relationships and other restrictions are defined among the subtasks (horizontal relationships). The notation for the Dialogue Model is based on the CTT notation. For more detail about the original notation, refer to [Paternò 2000]. For more detail about the adaptation of the notation in Wisdom, refer to [Nunes and Cunha 2001]. Figure 55 shows part of the Dialogue Model for the case study. The “Check availability and price” task step in Figure 51 is refined into a tree of subtasks. These modelling primitives are a mixture of actions that are related to the input message building phase; task classes are conceptually aligned to a generalisation of actions of the IS model. For example, the “Enter start date and duration” is related to the Editing and encoding of the input message; “Show


99

availability” is related to the Decoding and display of output messages; “Define period” and its subtasks induce form constraints that are related to the Metalinguistic context recovery. Note the exclusive-or relationship between the two subtasks.

Figure 55. Actions concerning the interfaces are specified in the Dialogue Model

The Presentation Model specifies the structure of the user interface in an abstract way by means of interaction spaces. An interaction space models the space within the user interface of an application where the users interact with all the containers, message editing facilities, and information needed to carry out their tasks (which are modelled in the Dialogue Model). The interaction space is a heterogeneous aggregation of the Coded input and output messages and the actions related to the IS reaction (see this alignment in Figure 56). A top-down decomposition of the interaction spaces is done; the “Hotel availability” browser is composed of several low-level interaction spaces. The “Period” interaction space specifies part of the Coded input message. Surprisingly, the “Room type” is considered to be an output element when in fact it is part of the Coded input message (see the original model


100

as illustrated in [Nunes and Cunha 2001]). The confusion may come from the fact that the edition of this field is being aided by a Linguistic context recovery. The room type is selected among those offered by the hotel. In other words, the edition is guided by offering the domain to the user. The “Availability status” specifies a Coded output message. The interface structure being defined is part of the Metalinguistic context recovery that is previous to the edition and display of messages. Furthermore, interaction spaces also embed the specification of actions. The “Hotel availability browser” defines methods related to the IS reaction. In contrast to the heterogeneous aggregation of analysis classes (see Figure 53), in this case, the actand-action duality is oriented towards the interface. Instead of the Information base entities, now the coded messages are involved; namely Coded input message and Coded output message.

Figure 56. Interaction spaces specify the interface from an object-oriented perspective

The Presentation Model also specifies the navigation between higher level interaction spaces. During the implementation phase, this model will lead to windows and their navigation.


101

7. OO-METHOD

7.1. The OO-Method at a glance

As briefly mentioned above, OO-Method is a software development method that clearly separates the Problem Space (what we want to build) and the Solution Space (how we are going to build it). The problem is defined as a Conceptual Schema (an abstract description of an IS), disregarding the implementation technology. Therefore, the OO-Method is compliant with the MDA paradigm. The tools that support the OO-Method allow the separation of the logic of software systems from their (multiple) possible implementations. The formalism underlying OO-Method is OASIS, a formal and object-oriented specification language for the specification of ISs [Pastor, Hayes et al. 1992]. This formal framework provides a characterisation of the conceptual elements needed to accurately specify an IS. It encompasses two main components: the Conceptual Model and the Execution Model. Since the Execution Model is the characterisation of how a conceptual model is implemented in a target technology (e.g. Java, .NET), we will focus on the OO-Method Conceptual Model. The modelling primitives of the Conceptual Model are conceptually aligned with regard to the generic model of ISs.

Figure 57. OO-Method workflow

The Conceptual Model comprises four complementary views: the Domain Model (or Object Model), the Dynamic Model, the Functional Model and the Presentation Model. All of them together constitute the whole Conceptual Model specification. These four views allow the definition of all structural and functional aspects of a system in an abstract (implementation-independent) yet accurate fashion by means of a set of modelling primitives. All the modelling primitives (or conceptual patterns) are conferred a precise semantics and have a UML-based graphical notation. The graphical notation hides from the modeller the complexity of the underlying OASIS formal specification. More details can be found in [Pastor, Gómez et al. 2001] and [Molina, Meliá et al. 2002].


102

Currently, OO-Method offers various proposals for requirements elicitation. One of this proposals focuses on functional requirements [Insfran 02]. It produces a Functional Requirements Model that is composed of several models: Mission Statement, Functional Refinement tree, and Use Cases. These models have a mapping with some models of the Conceptual Model (namely, Object Model, Dynamic Model, and Functional Model). Therefore, parts of these models can be derived by applying transformation rules to the Functional Requirements Model. In order to elicit interaction requirements, the formal notation ConcurTaskTrees (CTT) is used. This notation is a technique that is well-know in the Human Computer Interaction community. A set of interaction patterns is defined to build CTT models. These patterns are defined with a very precise syntax and semantics. Moreover, transformation rules are defined to transform the Task Model into the OO-Method Presentation Model, which specifies the user interface in an abstract and platform-independent way. However, since editing the CTT models is hard work, OO-Method proposes superimposing a layer to the CTT diagram in order to capture interaction requirements using sketches. CTT models are synchronously generated from these sketches. Because this transformation is ‘transparent’ to the analyst, s/he only needs to draw the sketches during the interaction requirements elicitation. Appendix F describes the Interaction Requirements modelling technique with more detail. In order to exemplify the method, we will use a case study. The case study is based on a real IS that was developed for a water supply company, Aguas Del Bullent. The company mission is to supply water to its subscribers. The company reads the meters in order to bill the water usage. For the sake of simplicity, only part of the conceptual model will be showed herein.

7.2. Conceptual alignment of some OO-Method models

In accordance with the notation explained at the beginning of Section 4, we develop the following conceptual alignment of the OO-Method with respect to the reference framework. The following sequence of diagrams describes the OO-Method Conceptual Modelling phase in terms of its corresponding conceptual alignment.

7.2.1. Requirements Model

The case study starts with the stage of requirements elicitation. The Mission Statement is a high-level description of the nature and purpose of the system. This element describes what the system will and will not do. The Mission Statement is related with the mission of the organisation and it is therefore aligned to Organisartional goals. The Function Refinement Tree (FRT) represents the hierarchical decomposition of the business functions of a system, independently of the current system structure. Each tree leaf is a function of the system. The leaves are grouped into internal tree nodes that group related business functions. Both internal tree nodes and tree leafs are a representation of an aggregation of system interactions so they are aligned with a generalisation of actions on the Information System. Each tree leaf is considered to be a use case.


103

Coded input

message


recovery


feedback


message

Linguistic context

recovery

Coded output

message

Interface processor

Information Base

entity(ies)

Input message

Output message

Reaction processor


of output message


message


message

Primary actor

BULLENT’s WATERTHE GOAL OF THIS ORGANISATION IS TO SUPPLY WATER TO CUSTOMERS AND TO MANAGE ITS STAFF AND RESOURCES

SUSCRIBERS

SUSCRIBER WATER METER TRANSFER

LIST SUSCRIBERS

NEW SUSCRIBER

LIST METERS

NEW METER

NEW DESTINATION

ORDER TRANSFER

CANCEL TRANSFER

INVOICE

EMIT INVOICE

LIST PAYED INVOICES

UPDATE CURRENCY

CLIENTS

ACCOUNTING

SHOW REPORTS

CHECK CREDIT

ADD READING



Figure 58. Mission Statement and Function Refinement Tree in OO-Method

To keep the example simple, this paper focuses only on one use case, List meters. This use case represents the functionality of showing a list with all the information about the water meters stored in the system.


104

Coded input

message


recovery


feedback


message

Linguistic context

recovery

Coded output

message

Interface processor

Information Base

entity(ies)

Input message

Output message

Reaction processor


of output message


message


message

Primary actor

WORKER

LIST METERSLIST SUSCRIBERS

ADD READING

NEW SUBSCRIBER

SHOW CUSTOMER REPORTS

EMIT INVOICE

UPDATE CURRENCY

Figure 59. Partial view of the Use-Case Model in OO-Method

Figure 59 shows a partial view of the Use-Case Model. Since this case study is based on a real industrial project, the Use-Case Model is quite big. Only a few use cases are shown here. Use cases are aligned to an aggregation of IS actions, just as FRT nodes (after all, tree leafs and use cases are two representations of the same ontological concept. After the Use-Case Model is created, the analyst specifies the details of each use case by means of use-case templates. Figure 60 shows a use-case template that specifies the steps required to accomplish the goal of the List meters use case. Again, for the sake of simplicity, the template does not fully comply with the notation described in [Díaz, Losavio et al. 2004] but it does specify the use case in detail. Use-case templates allow the specification of many different details of the interaction referred by the use case. These details are covered by other modelling primitives in later stages of the


105

development process. For the purpose of the conceptual alignment, we align it to an aggregation of IS actions. We acknowledge that this mapping could be further refined.

Coded input

message


recovery


feedback


message

Linguistic context

recovery

Coded output

message

Interface processor

Information Base

entity(ies)

Input message

Output message

Reaction processor


of output message


message


message

Primary actor

1. The user press the menu option called “List Meters”

ALTERNATIVE PATH (“ALL” FILTER)F.1 The user filles out some of the filter variables: Customer, Model, Serial, Number, Zone, Calibre

ALTERNATIVE PATH (“ZONE AND MODEL” FILTER)F.2 The user filles out some of the filter variables: Zone, Model

2. The system shows the meters list

ALTERNATIVE PATH (ORDER CRITERIA)O.1 The user select the order criteria to order the meters by Serial Number and Code of the Zone (Ascending)

3. The user select an instance

ALTERNATIVE PATH (NAVIGATION)N1. The user selects a Navigation between these: Subscriber, Reading, Route order, History, Calibre

ALTERNATIVE PATH (ACTION)A1. The user selects an Action between these: New Meter, Modify Meter, Delete Meter, Add reading, Last reading

USE CASE: LIST METERS

Figure 60. Use-case specification template in OO-Method

After functional requirements have been specified, the analyst focuses in interaction requirements. OO-Method provides a modelling technique that combines task trees and user interface sketches (see Figure 61). Since the task tree remains transparent to the analyst and is only intended to be the underlying formalisation of the user interface sketch, we will only align the sketch. Sketches are created as a draft of the final user interface with which the user will interact.


106

This way, it is a representation of a very late artefact of the development process and it has a low abstraction level. OO-Method defines a set of mappings among the sketching primitives and the presentation patterns (abstract interface modelling primitives). This way, the same alignment that is defined for presentation patterns is valid for sketching primitives. Therefore, we will align the sketch with a heterogeneous aggregation of actions and actands of the IS. Later on, a detailed alignment of presentation patterns will clarify the alignment.

Coded input

message


recovery


feedback


message

Linguistic context

recovery

Coded output

message

Interface processor

Information Base

entity(ies)

Input message

Output message

Reaction processor


of output message


message


message

Primary actor

Close

Zone #Meter Model Subscriber Address

Subscriber Readings Calibre

New

Modif

Delete

F FF F F F FO O

Figure 61. Sketch of the List meters use case

The CTT that represents the sketch is automatically built (see Figure 62). This technique is not conceptually aligned because its modelling primitives have a 1..1 relationship with sketching modelling primitives. The task model is only meant to support the sketch in a formal fashion.


107

Figure 62. CTT model corresponding to the sketch in Figure 61

7.2.2. Conceptual Model

After requirements elicitation, the next activity in the OO-Method workflow is conceptual modelling (a.k.a. system analysis, see Figure 57).

7.2.2.1. Specification of the Information System memory

OO-Method proposes to start by identifying the IS memory components. The specification of the static part of the OO-Method Domain Model is the natural starting point for the OO-Method proposal. Object orientation proposes to create models that describe ISs in terms of classes of objects. Each of these models offers a static view that is related to the memory of the IS; that is, the structure of related entities is able to register the facts occurred in the Subject System. This aspect of the model, shown in Figure 63, do not differ significantly from other approaches as the Entity-Relationship model [Chen 1976]. The specification of class attributes and class relationships constitutes the identification of the relevant entities of the Domain Model. This aspect of the classes of objects corresponds to the Information base entities in the conceptual framework. This is why this actand is represented with a thick line and grey background. Although the case study is quite broad, we have focused our attention to the main classes. Each water meter measures the water that is consumed by one customer. Periodically, the company reads the meters and enters the consumed cubic meters in the system.


108


message


message

Interfaceprocessor

Coded input

message

Coded output

message


of output message


recovery

Information base

update and reaction feedback

Linguistic context

recovery

Information base

entity(ies)

Reactionprocessor

meter_idmeter#serial#model

WATER METER

1..11..N

0..M

1..1

subscriber_idfiscal#nameaddress

SUBSCRIBER

reading_iddatecubic_meters

READING

Figure 63. Identifying the entities of the Domain Model

7.2.2.2. Specification of the Information System reaction

Now then, object orientation also proposes to encapsulate the IS reaction inside the classes of objects. Once the IS memory has been considered, it is time to assign system reaction to the entities of the Domain Model. This is done in the OO-Method by determining class operations and specifying them in the objectual Domain Model (see Figure 64), by creating the state diagram that constitutes the OO-Method Dynamic Model (see Figure 66), and by creating the Functional Model, where the effect that every class operation has on the object state is declaratively specified (see Figure 67).


109

Figure 64. Assigning system functionality to entities of the Domain Model

In Figure 64 we can see how the Information base update and reaction feedback represents the action that directly interacts with the Information base entities, and how the Interface processor actor is responsible for specifying the operation that will be sent to the Information System reaction box. This aspect, that is related to IS reaction, completes the class-diagram-based view of the IS model. For each class of the case study, its operations are defined. For example, water meters can be created, its data can be changed, a reading can be added (this operation, which is shared with the Reading class, creates a relationship between instances of both classes) and finally the water meter can be deleted. Also, a class is included to model the IS user. Relationships stereotyped with the tag <<agent>> denote the responsibilities of the user; that is, which class operations does the user trigger. Only a few of these relationships are shown in the model. Agents are mapped to the Interface processor ontological concept. As it is argued above, class diagrams combine two aspects of the IS. More precisely, two ontological concepts are projected onto the same modelling primitive. This is why the alignment in Figure 65 is equivalent to the alignments shown in Figures 63 and 64. The modelling primitive for the classes of (business)


110

objects is aligned to a heterogeneous aggregation of Information base entities and Information base update and reaction feedback.


message


message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message


of output message


recovery


feedback

Linguistic context

recovery

Information base

entity(ies)

new_meter(...)change(...)add_reading(...)delete(...)

meter_idmeter#serial#model

WATER METER

1..11..N

0..M

1..1

new_user(...)

loginname

USER

<<agent>>

new(...)modify(...)sign_off(...)sign_up(...)delete(...)

subscriber_idfiscal#nameaddress

SUBSCRIBER

new(…)add_reading(..)

reading_iddatecubic_meters

READING

Figure 65. Classes are heterogeneous aggregations of static and functional aspects

A clear example of ellipsis appears in this conceptual alignment: the Edition and encoding of input message, the Coded input message, the Coded output message and the Decoding and display of output message remain without mapping. In this case the ellipsis was consciously introduced by the method, since the way the input message is edited and encoded is not the focus of these models of the IS. As explained in Section 7.2.2.3, this is accomplished by a fourth view of the OO-Method conceptual model named Presentation Model. The Dynamic and Functional Models (see Figures 66 and 67) accurately describe the behaviour by means of state diagrams and abstract instructions that specify how the IS reacts to input messages.


111

WATER METERSUBSCRIBER

IN_USEnew_meter

change

add_reading

delete


message


message

Interfaceprocessor

Reactionprocessor

Coded input

message

Coded output

message


of output message


recovery


feedback

Linguistic context

recovery

Information base

entity(ies)

SUBS-CRIBED

new

modify

sign_offdeleteUNSUBS-

CRIBED

sign_up

Figure 66. Specifying behaviour in the Dynamic Model

Dynamic Model has the following primitives: class states and transitions. Functional Model has the following primitives: valuations, local transactions and global transactions. The modelling primitives of both models are mapped to the Information base update and reaction feedback ontological element. It may appear as if these models are localised decompositions, since the reaction is refined locally (the lifecycle of each class is specified, the reaction corresponding to each class method is specified). However, this is typical of refinement and it does not necessarily imply localisation. It can be noted that no relation among elements of different classes can be specified.


112

Figure 67. Specifying reaction in the Functional Model

The reaction of each of the class methods identified during the specification of system memory (see Section 7.2.2.1) is refined (by means of decomposition) in the Fuctional Model. Also included in the Functional Model, there is an emergent level that describes: (a) reactions that can not be assigned to a specific object instance but to an object class –local transactions-, (b) reactions that can not be assigned to a specific object class because it affects several classes –global transactions-. The emergent level also deals with refinement by decomposition but, in this case, it is accomplished in a bottom-up sense. Figure 68 shows how methods can only affect one instance of one class, local transactions can affect several instances of only one class, and global transactions can affect several instances of many classes. This figure only serves as an explanation of the Functional Model; it is not intended to serve as a metamodel of any part of the OO-Method Conceptual Model.

Figure 68. How elements of the Functional Model affect instances.


113

7.2.2.3. Specification of the Information System interface

Once static class architecture and system functionality has been specified, the last step is the specification of the user-system interaction. In the OO-Method proposal, this is accomplished by creating the Presentation Model.

Figure 69. The user-interface patterns are object-oriented

Figure 69 illustrates the corresponding conceptual alignment. In this case, the OO-Method Presentation Model is conceptually aligned with a heterogeneous aggregation of the Coded input message and the Coded output message actands, and the Information System reaction. These messages are assumed to be properly processed by the IS, as specified in the models related to IS reaction (Section 0). In general terms, the Presentation Model offers a set of modelling primitives (presentation patterns) that allows the description of the interface. Figure 70 shows a more detailed conceptual alignment of these primitives. The presentation patterns are organised in three levels. The first level is called the Action Hierarchy


114

Tree and it models the menu of the software application; it is therefore related to the localisation of editorial environments. This level is not depicted in Figures 69 and 70 because the graphical view of the generic model of ISs does not include an element related to localisation. The second level offers a set of presentation patterns that are called interaction units (IUs). IUs are abstract, reusable pieces of an editorial context. Unlike the presentation units [Bodart and Vanderdonckt 1996] (modelling primitives that inspired the IUs), IUs not only deal with presentation but also support behavioural and task constraints. There exist four types of IUs:

• A service IU models a piece of the interface that will support the edition of an input message; this primitive is mapped to the Coded input message element.

• An instance IU models a piece of the interface that will display information about a class instance.

• A population IU models a piece of the interface that will display a set of instances of a class. Both Instance and Population IUs correspond to the Coded output message.

• A master/detail IU is merely a structured composition of instance and population IUs with given relationships among them.

The third level of presentation patterns offers a set of elementary patterns. These patterns constitute the primitive building blocks of the user interface and allow the restriction of the structure and behaviour of the interaction units described above.

• Argument grouping. It defines which (input message) data fields are closely related and should therefore be displayed following the grouping laws studied by the Gestalt Theory [Wertheimer 1938]. These groupings reinforce the perception of the message structure and are therefore related to the Metalinguistic context recovery.

• Dependency. This pattern models the restrictions and interdependencies among (input message) data fields by means of event-condition-action rules (similar to the ones used in databases to define triggers). There are two different uses of the Dependency pattern:

o The Dependency pattern can be used to express a structural specialisation of a message. In this case the pattern watches over the fulfilment of the message structure, and it is therefore related to the Metalinguistic context recovery. In the following example (adapted from [Molina 2003], p. 326), the data field corresponding to a person’s salary is only active in case this person has a job. Event: HasJob.Changed Condition: HasJob.Value='Yes' Action: Salary.SetActive(true) Event: HasJob.Changed Condition: HasJob.Value='No' Action: Salary.SetActive(false); Salary.Value=0

o The Dependency pattern can also be used to express that the value of a data field depends on the values of other data fields. A derivation formula is defined. In this case the pattern deals with the Derivation of facts. New facts are derived from already-known facts (Information base entities) and facts that have just been


115

introduced by the Interface processor. In the following example, the amount of an order line is calculated multiplying the price of the product by the number of items demanded. Event: NumItems.Changed Condition: Price.HasValue Action: Amount.Value = Price.Value * NumItems.Value Event: Price.Changed Condition: NumItems.HasValue Action: Amount.Value = Price.Value * NumItems.Value

Figure 70. Specifying edition and display of messages in the Presentation Model

• Introduction. It captures the main features of (input message) data fields. It is used to specify several features such as

1. the label of the data field (referred to as alias), 2. whether the data field is optional or not,


116

3. the edit mask, 4. a message aimed to help the user in editing the field, 5. error messages associated with the data field, 6. the range of accepted values, 7. the default value, and 8. the maximum length in characters.

As argued in Section III.6, the definition of message structure (2), the constraints on the format of fields (3), help for the editing (1,4), and error messages (5) are forms of Metalinguistic context recovery. Constraints on the domain of the fields (6,8) and their initial values (7) are forms of Linguistic context recovery.

• Display set. It specifies the set of attributes of a class that will be shown to the user in an instance or population IU. This pattern is part of the definition of the output message structure and is therefore related to the Metalinguistic context recovery.

• Filter. This pattern models an editorial facility that will allow the user to define selection criteria and obtain the instances that fulfil the expressed constraint. This facility helps to deal with large quantity of data (facts memorised by the IS) and is therefore related to the Linguistic context recovery. As argued in Section III.2, output dialogs still need some information input; filters and order criteria model this aspect of the interaction.

• Order criteria. It defines how instances (of an output message) have to be ordered, using the values of one or several attributes of the display set. Since it deals with factual information, it is also part of the Metalinguistic context recovery.

• Supplementary information. It defines a set of data fields that will feedback the user information about the selected instance, whenever an identifier is chosen. This pattern recovers factual information from the information base and is therefore a form of Linguistic context recovery.

• Defined selection. It specifies an enumerated domain for a (input message) data field; this pattern is applied when it is possible to define a well-know closed set of values for a data field. The defined selection is a form of Linguistic context recovery.

• State recovery. It defines which (input message) data fields take value when an object is selected to show the current value, so the user can change their value. The state recovery is a form of Linguistic context recovery.

• Actions and navigation. These patterns model editorial context localisation. The difference between both patterns is subtle; actions give access to service IUs while navigation gives access to instance and population IUs. In fact, in interface design both patterns are typically referred to as navigation. Localisation is not addressed in our generic IS model, so it is not possible to align these modelling primitives.

It should be noted that three of the elementary patterns are quite similar in their purpose. Dependency (in its derivation-formula usage), supplementary information,


117

and state recovery all cover Linguistic context recovery by recovering the values of one or several data fields. The difference among them is a question of the user interaction that triggers them. We acknowledge that it is arguable whether Order and Filter patterns are related to Linguistic context recovery (since the execution of these patterns deals with factual information) or they are related to Metalinguistic context recovery (since the definition of these patterns specifies an aspect of the message structure). Just as a proof of concept, Figure 71 shows the user interface for the List Meters use case, as it is generated by the OLIVANOVA Model Compiler.

Figure 71. Automatically generated user interface for the List meters use case.

7.2.2.4. Specification of the Organisational System reaction

It should be noted that the OS reaction, which is an element of the full conceptual framework, is not covered by the OO-Method Conceptual Modelling. This occurs because the requirements modelling phase is not subsumed by the conceptual modelling strategy provided by OO-Method.

7.3. Some comments on the OO-Method and the MDA

In 2001, the Object Management Group proposed an increasingly popular paradigm: the Model Driven Architecture (MDA) [OMG 2003a]. This de facto standard defines how to apply Model Driven Development. Three viewpoints were proposed (see Figure 72):

• A Computation Independent Model focuses on the environment and the requirements of the system.

• A Platform Independent Model (PIM) focuses on the operation of the system, which stays constant across any possible technological platform.

• A Platform Specific Model (PSM) aims to provide the platform-dependent viewpoint with those features that are specific to a platform.


118

As defined by the Object Management Group, a model transformation is the process of converting one model to another model of the same system. Commonly, the target model is in a lower abstraction level than the source model and, therefore, it is closer to the final implementation. By means of consecutive transformations, we end up with an executable model of the system: the Code Model.

SYSTEM ANALYSIS

REQUIREMENTS ELICITATION

COMPUTATION INDEPENDENT

MODEL

PLATFORM INDEPENDENT

MODEL

SYSTEM DESIGN

PLATFORM SPECIFIC MODEL

CODE MODELIMPLEMENTATION

Activity

Product

Input/ Output flow

LEGEND

Figure 72. MDA generic process and models

Transformations can be applied manually, with computer assistance, or automatically. Although the standard is not restrictive, it seems sensible to automate transformations whenever this is feasible. Transformation rules have to be unambiguously specified using some language, regardless of the degree of automation. Again there is a wide choice, ranging from natural language descriptions to QVT [OMG 2005b] specifications. Among the several model transformation approaches that can be used, the Metamodel Transformation deserves our special attention. Transformation rules are defined in terms of the source and target metamodels (see Figure 73). The definition of transformation rules is a hard task but it benefits analysts in many ways:

• Complete support for the software life cycle from requirements to maintenance.

• Reduction of software development costs. Analysts put their main effort in the analysis stage. Subsequent stages are facilitated by automatically deriving initial models that are refined by the analysts. This saves time and resources.

• Quality improvement. Code generation reduces the possibility of error. The same model can be transformed into code for several programming languages.


119

Figure 73. Metamodel Transformation

The advantages of using a model transformation approach have more weight than the effort required to define transformation rules. For this reason, several Model Transformation Technologies have recently appeared in order to generate code from Conceptual Models [Ceri, Fraternali et al. 2000; Olivé 2005]. However, defining correct and useful transformations is a hard task for method designers. Moreover, some MDA environments implement MDA models with a combination of several models. The route from the CIM to the Final Code can be quite tortuous, because the analyst has to construct a large number of models.

Figure 74. Comparison between MDA and the OO-Method

Furthermore, depending on a number of contingencies, the sequence in which the analyst fills out the models may change. For example, a CIM can be composed of several requirements models. The order in which they are built may be determined by the type of user that is formulating the requirements. Certain requirements models can be more appropriate for initiating capturing requirements with an expert computer user than others. Figure 74 shows rthe correspondence between models of the OO-Method approach and tha latyers of the MDA paradigm.


120

Software development methods usually offer several modelling techniques. The aim is that models complement each other and offer various perspectives on reality. In some cases, the complementary nature of the perspectives is horizontal. For example, aspect-oriented methods seek to segregate cross-cutting concerns that are observable at a certain abstraction level. In other cases, the complementary nature of the perspectives is vertical. The aim is to segregate the different abstraction levels of the descriptions. For example, Data Flow Diagrams allow the level of detail of system descriptions to be increased by means of stepwise refinement. The four views of the OO-Method Conceptual Model (Object, Dynamic, Functional and Presentation Models) also specify complementary perspectives on reality. For example, the Functional Model offers a horizontal complementary perspective with respect to the other three models. The Functional Model deals with aspects related to Information System (IS) reaction while the other models specify IS memory and IS interface. However, the Object Model already has a dynamic part that structures IS reaction in terms of class methods. The Functional Model refines class methods by decomposition so, in this sense, it also offers a vertical complement to the Object Model. Further argumentation on the use of complementary perspectives can be found in Section 2. The MDA paradigm proposes criteria to structure system descriptions in different layers. Having reached this point, a question arises: whether the complementary nature of the MDA layers is horizontal or vertical. MDA model definitions do not clarify this issue. Another question is whether the MDA criteria are pragmatic in real projects. As Figure 75 depicts and we later argue, the MDA frontier between CIM and PIM layers cuts across the OO-Method requirements models diagonally. Figure 75 zooms in on the first two MDA layers shown in Figure 74.

Figure 75. The MDA layers and the OO-Method – pragmatics going beyond frontiers


121

The MDA paradigm would be extremely easy and powerful if it were possible to follow a cascade software-development lifecycle. For this to work, one person would start building the models of the highest abstraction level. The subsequent models would then be manually or automatically derived, each time adding the details related to the new abstraction level. However, since reality is often very complex, the iterative and incremental development paradigm is more practical and popular. MDA adapts well to this way of working. One can start by modelling one part of the system and feeling one’s way down the abstraction ladder. When this part of the system is more or less consolidated and perhaps even implemented and deployed, a new iteration starts. Another part of the system is modelled top-down. In an MDA-based iterative software development, either it is possible to partition the system with surgical precision, seeking a high cohesion and minimal coupling between the parts, or automatic transformations arise as a strong need. As stated in Section II.2.3, the analysis and development of Information Systems is a ‘wicked problem’ [Rittel and Webber 1973]. The solution to that problem (i.e. the Computerised Information System) is not right or wrong, but better or worse to other possible solutions. It is the human dimension of Information Systems what increases the complexity. The consequence of this tangle of cognitive, social and abstraction-level issues is that no single ingenuous solution is adequate. Methodologists need to offer software-development strategies that facilitate opportunity-driven problem solving. An evident corollary is that it is important to deal with contingency in software development. Methods must be flexible in the sense that the techniques to be applied in each moment are determined by various factors: the characteristics of the system to be computerised (i.e., automatic teller machines are not dealt with the same way as ISs), the nature of a specific problem presented at a given moment (e.g. to design a user interface, to specify business objects, to design strategic-level reports), the expertise of the development team (which techniques they know best), the maturity of the organisational system, the users’ organisational and technological knowledge, the predisposition of the stakeholders to be involved in development, etc. With regards to the MDA paradigm, the number and variety of these issues give it a complexity akin to a jigsaw puzzle. Methodological confusion among practitioners appears, worsened by the fuzziness with which most methods and techniques are defined. Because of the lack of sound criteria, gurus proliferate, and practitioners try to make up for a lack of adequate methodological guides by generalising from examples and case studies. The solution to all of this, i.e. piecing together a well founded method requires a number of issues to consider:

1. Theoretical soundness should be assured. This requires the basing of argumentations on unambiguous and well-defined concepts.

2. The usage of techniques should be specified. Modelling techniques are often offered by their authors as a panacea for all problems. Also, many modelling primitives can be used to describe things at different abstraction levels; techniques should be located in the methodological jigsaw puzzle, reducing the degrees of freedom with which they are marketed.

3. Method design that aims to facilitate opportunity-driven problem solving. 4. Provision is made for contingencies. This may be achieved by offering

several alternative routes aimed at completing the methodological jigsaw


122

puzzle. The routes should be appropriate for overcoming problems during complex projects.

5. To empirically assess all the alternative methodological routes. It is convenient to carry out a series of empirical tests to evaluate their viability, pros and cons.

We will now clarify the issues commented above with an example using some of the methodological pieces of the OO-Method (see Figure 74). Firstly (issue 1), one way of gaining deeper knowledge about a method is to conceptually align it with an ontology, a set of well-defined related concepts. This ontology must be appropriate for the type of problem that will be solved using the method. In this work the OO-Method Conceptual Model is aligned with regard to a conceptual framework concerning Information Systems. Each method must locate and place the pieces of its puzzle depending on the semantics associated with the modelling techniques being proposed (issue 2). For example, there is no consensus with regard to the criteria underlying Use Cases. As things stand, the Rational Unified Process (RUP) proposes to distinguish between business use cases and (computerised system) use cases. In the case of the OO-Method Functional Requirements Model, use cases are located at the CIM level (as the RUP business use cases), as Figure 75 shows. This implies that no computerisation aspects should be considered at this level. Use-Case Templates are also designed to be computation-independent. However, Sequence Diagrams decompose the IS in terms of objects that react to external and internal messages and many of them presuppose a computerisation of the system; for this reason, Sequence Diagrams in the OO-Method are not located at the CIM level, but rather at the PIM level. Particularly interesting is the case of the Interaction Requirements Model. While task trees can be argued to focus on the interaction between the user and the system, it is still arguable whether the system refers to an Information System or a Computerised Information System. In our proposal, the CTT notation is used as a computation-independent description of the interaction. By determining the semantics of each modelling primitive in a computationally independent way, we can fix the task model at the CIM. However, the sketch of the interface is evidently oriented towards a computerisation. Our sketching primitives are still independent of the particular programming and runtime environment, so the user interface sketches are claimed as part of the PIM. Figure 75 shows how the Functional and the Interaction Requirements Model are crossed diagonally by an MDA frontier. In the OO-Method we confront the challenge in order to facilitate opportunity-driven problem solving (issue 3). We offer the chance to go up and down in the abstraction layers depending on the specific problems that the developers come across during a software project. Automatic transformations and the compilation of the Conceptual Model allow for an incremental development. Also, these transformations permit the testing and validation of partial solutions at a low cost. For a real opportunity-driven approach to be possible, the problem of inter-model incoherence must be dealt with. Sometimes a model B has been derived from a model A that is of a higher abstraction layer. Later, B is modified and details are added to it. Then it may occur that models A and B are no longer consistent. This problem is solved by round-trip engineering; that is, by offering support for the bottom-up propagation of changes in the models. In the case of the OO-Method Conceptual Model and the Code Model, the stress is put in the Extreme Non-Programming paradigm [Morgan 2002]; that is, no changes should be made to the


123

code. However, current tools are not so refined, and when this is really needed, a Tweaking application solves the round-trip problem. Between the Conceptual Model and the Requirements Models, the round-trip problem is an issue still requiring a great deal of research, although some promising strategies are being tested. When solving complex problems, contingencies must be dealt with appropriately. The development team may need to take different routes through the method (issue 4). All these methodological routes must be theoretically and practically achievable. Within the MDA paradigm, the routes usually involve manual derivations and (semi)automatic transformations among the models. In the OO-Method, we offer several routes (see Figure 74). In the case of the OO-Method Functional Requirements Model, the analyst can chose between describing use cases via specification templates or via sequence diagrams. The Interaction Requirements Model is optional; it will not be necessary whenever the system being developed does not have demanding user interface requirements. However, it is recommended to specify the interaction requirements of those use cases that are not CRUD-like30. Furthermore, on some occasions, it is even convenient to start with the Interaction Requirements Model for those parts of the system where the users already predispose some user interface sketches. This model then serves to establish a degree of shared knowledge between the users and the developers.

Figure 76. The MDA jigsaw puzzle in the OO-Method – aiming to support contingency

See Figure 75 for a graph where the vertices represent the proposed models (methodological pieces) and the arcs represent transformations and mappings

30 Create, Read, Update and Delete are typical actions in Information Systems


124

among the models. The core of the OO-Method is the Conceptual Model. Above it, at the functional requirements level, there are several proposals. In this paper we only present those proposals related to use cases. A different approach is described in [DeLaVara and Sánchez 2007], where the authors present an adaptation of BPMN to fit the OO-Method. The analyst will choose the most appropriate technique depending on the problem being solved (i.e., the system being developed). The OO-Method is also being extended at the lower abstraction levels. In order to give more expressiveness to the interface modelling, a concrete interface model [Pederiva, Vanderdonckt et al. 2007] is being researched to deal with issues like widgets, alignment, look and feel, etc. We can argue that our approach is theoretically valid. The different methodological routes are well-founded and the corresponding derivations and transformations are offered. However, not all of the routes necessarily give good results in all cases. We acknowledge that it is even possible that some routes are not convenient at all. This is closely related to empirical validation of methodological routes (issue 5). Evaluating situational methods (what we have called routes across the jigsaw puzzle) is one of the topics of interest of Method Engineering [Fitzgerald 1991] [Schipper and Joosten 1996].


125

8. Further argumentation

During the conceptual alignment of software development methods, several issues have arised. Also, some we have learned some lessons. It has been revealed that conceptually aligning software development methods is not an easy task due to several factors. These factors are enumerated as shortcomings of the ontological analysis by Rosemann et al. [Rosemann, Green et al. 2004]. We claim to have overcome some of them. Other shortcomings are still present in our work. In the following, several shortcomings of ontological evaluation are enumerated (see Figure 77). Explanations between brackets are extracted from [Rosemann, Green et al. 2004].

Figure 77. Ontological analysis shortcomings enumerated in [Rosemann, Green et al.

2004]

• Lack of understandability. “Most of the ontologies that are currently used for analysing modelling grammars have been specified in formal languages. While such formalisation is beneficial for a complete and precise specification of the ontology, it is not a very natural or intuitive specification. An ontology that is not clear and intuitive can lead to misinterpretations as the involved stakeholders have problems with the specifications.” The ontology introduced in this work is specified in plain English; that is, no formal language has been used. Also, examples have been used where it was considered necessary. Therefore, the ontology is expected to be understandable.

• Lack of comparability. “Even if an ontology is specified in an intuitive and understandable language, the actual comparison with the selected modelling grammar remains a problem. Unless the ontology and the grammar are specified in the same language, it will be up to the coder to ‘mentally convert’ the two specifications into each other for comparison purposes, which adds a subjective element to the analysis. Different languages can also lead to different levels of detail and further complicate the analysis.” The approach followed in this work suffers from the same subjectivity as other ontological analyses do. Many interpretations are done while conducting the analysis.

• Lack of completeness. “It is up to the researcher to clearly specify the selected version of the ontology and the scope and level of detail of the analysis.” In fact, we have stated that the reference ontology that we are using (ié´the IS conceptual framework) is focused on Information Systems.


126

“Many ontological analyses focus solely on the constructs of the ontology and the constructs of the grammar but do not sufficiently consider the relationships between these constructs. The difficulty of clearly specifying the boundaries of the analysis, as well as the limited consideration of relationships between the ontological constructs, can lead to a lack of completeness.” We claim that the conceptual framework of ISs includes a set of concepts coming from a variety of disciplines and that the procedure for the ontological analysis fosters a careful analysis of the conceptual alignment. The results of the conceptual alignment are not just a table with checks and crosses but an argumentation about the meaning of each modelling primitive and the assumptions made by the designers of the method.

• Lack of guidance. “It is typically up to the coder to decide on the procedure of the analysis, i.e. in what sequence will the ontological constructs and relationships be analysed? Currently, there are hardly any recommendations on where to start the analysis.” Most of the ontological analyses found in the literature focus on only one modelling technique. We have defined a procedure for performing the ontological analysis of a workflow of modelling activities. Therefore, the order in which the conceptual analysis is done is the order defined in the method workflow. This order is important since it is closely related to the method orientation (e.g. object oriented methods tend to first identify classes of objects and then to identify the functions assigned to them (class methods). Other orientations first focus on functions and then relate functions to the classes of objects they affect.

• Lack of objectivity. “Analyses are based on the individual interpretations of the involved researcher, which adds significant subjectivity to the results. This problem is further compounded by the fact that, unlike other qualitative research projects, ontological analyses typically do not include attempts to further validate the results.” This lack of objectivity is inherent to the interpretations in which evaluators base their ontological analysis. In order to gain objectivity, the ontological analyses shown in this work have been performed by three evaluators and agreement has been sought.

• Lack of adequate result representation. “The results of a complete ontological analysis, i.e. representation mapping and interpretation mapping, are typically summarised in two tables. These tables list all the ontological constructs (first table) and all the grammatical constructs (second table) and the corresponding constructs of the other meta model. Such tables can become quite lengthy and are typically not sorted in any particular order. They don’t provide any insights into the importance of identified deficiencies and they also don’t cluster the findings.” The outcomes of our ontological analyses are not a mere list of mappings, but a compete argumentation of the ontological concepts underlying the software development method. Examples are given, explanations are offered, problems or ambiguities are explicitly addressed. This results offer valuable insight into the method fundamentals.

• Lack of result classification. “It is common practice to derive ontological deficiencies based on a comparison of the constructs in the ontology and the grammar.” “In general, the ontological analysis does not make any statements regarding the relative importance of these findings in


127

comparison with each other.” “This lack of a more detailed statement regarding the significance of a potential shortcoming makes it difficult to judge quickly the outcomes of the results of two different sets of analyses.” It is true, however, that our presentation of the conceptual alignment could be more rigorous and also that it could classify the pros and cons of each method. We plan to improve this issue in future work.

• Lack of relevance. “Finally, the results of an ontological analysis should be perceived as relevant by the related stakeholders.” “It seems that an ontological analysis has to consider the purpose of the grammar as well as the background of the modeller who is applying this grammar. The application of a high-level and generic ontology does not consider this individual context and there is a danger that the outcomes can be perceived as trivial.” We have used a reference ontology that is specifically created to deal with Information Systems concepts. We use this ontology to perform the ontological analysis of Computerised Information Systems development methods. Therefore, the ontology is considered very appropriate for the grammars being analysed.

During ontological analyses, the evaluators realised that further refinement of the Information System reaction and the Coded input message would explain better how ISs support the editing of input messages and how ISs react to these messages. Therefore, we plan to consider an extension of the conceptual framework that addresses this refinement. Figure 78 shows a draft of this extension.

Figure 78. Draft of a further refinement of Information System reaction and Coded input message


128

V. On the ontological completeness of Situational Methods

129

V. ON THE ONTOLOGICAL COMPLETENESS OF SITUATIONAL

METHODS


130


131

1. Motivation

The Method Engineering community proposes to describe methods in terms of method fragments. A method fragment is some part of the definition of a method (e.g. a modelling technique, certain task definition). Method fragments are stored in a repository in order to allow their reuse and to facilitate their assembly. Method fragments are referred to as method chunks, method pieces or method components [Henderson-Sellers, González-Perez et al. 2007] [Henderson-Sellers, Gonzalez-Perez et al. 2008]. In either case, method fragments can be assembled to create a situational method. A situational method is a method that has been assembled in order to fit a particular situation; that is to say, the contingency of the situation determines method. Therefore, the situation is a set of factors that have impact in the design of the method. Typically, this set includes one or many of the following factors: characteristics of the project, such as project domain or project complexity, time and resource constraints, skill of the development team, skill of the other stakeholders (e.g. users). For a specific project, the method designer designs a situational method. The situational method needs to fulfil certain quality requirements. Completeness is one of these requirements. In short, in the context of this work, method completeness is the quality of a method that defines enough modelling techniques to specify all the facets of an Information System. Information Systems have been studied in detail in previous sections. A set of elements that can be said to compose an Information System has been proposed in Section III; that is, a conceptual framework about Information Systems. Also, Section IV has proposed a technique to assess which concepts of an Information Systems a software development method allows to specify; that is, conceptual alignment. Current section proposes a strategy to assess the ontological completeness of a situational method by using the previously defined conceptual framework and the conceptual alignment.


132

2. Related works on method completeness

There are many definitions of completeness, although these definitions have been done taking into account other domains different to Method Engineering:

“Method completeness measures the property of a modularization method to select, from an existing system, all the pieces of code that implement an abstraction” [Canfora, Cimitile et al. 1995].

Colomb and Weber discuss about ontological completeness of software development methods and they arrive to the conclusion that ontological completeness is a property of the language and reasoning system used to specify the information system” and it is “associated with the relationship between how an information system is specified and the semiotic system in which it is operated” [Colomb and Weber 1998]. They make the following definition of ontological adequacy:

“Ontological adequacy has been defined operationally as a property of the semiotic system used to specify the information system, evaluated with respect to Bunge's generalised ontology. In particular, every element of Bunge's generalised ontology must be represented in the generalised ontology governing the construction of the Information System Semiotic System.” [Colomb and Weber 1998]

Colomb and Weber borrow the expression ontological adequacy from Guarino [Guarino 1995]. Many authors refer to the Wand and Weber definition of completeness. For instance, Keen and Lakos define this way the ontological completeness of a modelling scheme (a.k.a. modelling technique):

“A system modelling scheme is defined as being ontologically complete if that scheme contains a design construct to represent every component in a given set of ontological design constructs. That is, the mapping from a given set of ontological design constructs to the set of design constructs provided by a system modelling scheme is total.” [Keen and Lakos 1996]

Figure 79. A framework for the evaluation of modelling techniques (from [Wand and Weber 1993])


133

“Informally, the notation of a model is ontologically complete if the notation can represent the same information as the representational model (the ontological constructs); otherwise, it is ontologically incomplete and suffers from construct deficit [26]. That is, a notation is ontologically complete if the representational mapping from the ontological constructs to the notational constructs is total.” [Gregersen and Jensen 1999]

ONTOLOGICAL CONCEPTS OF REFERENCE ONTOLGY

MODELLING PRIMITIVES OF A MODELLING TECHNIQUE

Figure 80. An ontologically complete modelling technique

Figure 80 shows a modelling technique that has been evaluated in relation to a reference ontology. This technique is considered ontologically complete because each and every ontological concept has a mapping to a modelling primitive. Using the terms of Wand and Webber, there appears no construct deficit. However, those approaches that follow the BWW approach to Information Systems understanding lack the social aspects of Information Systems. As it has been argued in Section II.3.4, Wand and Weber view Information Systems as mere representations of the real world. Therefore, the BWW model only addresses ontological concepts that are related to that view of Information Systems. On the other hand, the Information Systems ontology presented in this work (see Section III), includes many social aspects regarding Information Systems. Information Systems are viewed as a support to organisational communications (see Section II.1). This way, the proposed ontology contains ontological concepts related to social and communicational aspects of Information Systems. If the ontology proposed in this work is used as a reference ontology for the evaluation of the ontological completeness Information Systems modelling techniques, then this evaluation will also take into account social and communicational issues.


134

3. Evaluation of the ontological completeness of a Situational Method

3.1. Generic proposal

In the context of this work, ontological completeness of a modelling technique or a method (viewed as a set of modelling techniques) is the extent to which the ontological concepts of a reference ontology are mapped to the modelling primitives proposed by the modelling technique / method. As we are defining it, ontological completeness can be also referred to as specification coverage, in order to emphasise the fact that we focus on modelling and specification of the Information System, not in the construction of the Information System. This work focuses in situations where an Information System (IS) is being built. All the elements of the IS need to be specified (probably by means of models) before the implementation stage. The elements of the IS are specified following the guidelines that are given by method fragments; that is, with one method fragment, one or several types of IS element can be specified. By assembling various method fragments the method engineer can create a Situational Method that allows specifying all the types of elements of an IS. Then we can say that the assembled Situational Method covers the specification of all the types of elements of an IS. But three questions arise:

1. What types of IS element are there? 2. Which types of IS elements can be specified using a particular method

fragment? 3. Do we always need to specify all types of IS elements?

We propose an approach to the issue of ontological completeness. We use a model of a generic IS to identify the types of elements that constitute an IS. This model has been presented in Section III and has proved to be useful in determining the concepts underlying modelling techniques. This way, by indicating a reference ontology we can determine the types of IS elements that we are interested in (question 1). Then, it is possible take the modelling primitives offered by a given modelling technique and to align them conceptually to the elements of the generic IS model. This way we would assess what elements of the IS can be specified by using the method. This way we are able to answer question 2. This approach is graphically depicted in Figure 81. The figure shows a simplified example of a method that would not be considered as ontologically complete because some ontological concepts are not covered by the modelling primitives of the method.


135

Figure 81. Evaluating the ontological completeness of a method

However, the approach described above has not yet answered question 3: whether it is always necessary to specify all types of IS elements in every software development project. To answer this question we must take into account that a situational method is a method designed by means of assembling method fragments in order to fit a particular situation (a particular software development project). The situation of the project determines the needs to be addressed by the method. A given ontological concept might be needed to be covered in a specific situation. In a different situation this same ontological concept might not be needed. For instance, in a project that aims to develop a tailor-made application from scratch, developers need the specification of the system memory in order to create the database. Then, the analysts need to specify the memory of the Information System. For this reason, the method designer has to include a modelling technique that allows to specify the IS memory (e.g. UML class diagrams, Entity-Relationship models). However, let’s suppose another project in which the aim is to develop a software application, but now reusing a legacy database. Now the method does not need to include a modelling technique to model IS memory, since the IS memory is already implemented31. Then we can say that the situation determines which IS elements need to be specified; that is, depending on the situation, certain IS elements (ontological concepts) need to be specified. Figure 83 shows the mapping between the characteristics of a given situation and the ontological concepts of the reference ontology. Note that the dots in the situation represent the characteristics of the situation and that they are linked to a subset of the ontological concepts (only those that need to be specified).

31 Let’s also suppose that there is no need to model the legacy database. For instance, the development team receives an up-to-date documentation corresponding to the system in use (including the legacy database relational schema).


136

Figure 82. Determining the ontological concepts that need to be specified in a given

situation

A situational method is designed (by means of the assembly of method fragments) to satisfy the needs of a particular situation. Figure 83 shows the evaluation of the ontological completeness of the same method that appears in Figure 81. However, now it is considered that the method is going to be enacted in a given situation. The method conceptual alignment with respect to the reference ontology shows that modelling primitives of the situational method do not allow the specification of each and every ontological concept. In any case, at least the ‘needed’ ontological concepts can be specified using the modelling primitives of the situational method. Therefore, the method, in the given situation, can be considered ontologically complete; that is, the situational method is said to be ontologically complete.

Figure 83. Evaluating the ontological completeness of a situational method

Ontological completeness can be defined in relation to the difference between the ontological concepts that need to be specified and the ontological concepts that can be specified. Ontological completeness is the degree in which the needed


137

ontological concepts can be specified by the available modelling primitives. This can be expressed in terms of Set Theory. Let

CS be the set of characteristics of the given situation. OC be the set of ontological concepts of the reference ontology. MP be the set of modelling primitives proposed by the situational method. SN: CS x OC be a correspondence between characteristics of the situation and ontological concepts. SN represents the specification needs of the situation. CA: MP x OC be a correspondence between modelling primitives of a situational method and ontological concepts of a reference ontology. CA represents the conceptual alignment of the situational method with respect to the reference ontology.

Figure 84 shows the above-mentioned sets and relations.

CASN

OC

SC MP

OCn OCs

Figure 84. Sets and relations regarding situational method completeness

Let OCn = SN(SC) be the set of ontological concepts of the reference ontology that need to be specified, according to a given situation. OCs = CA(MP) be the set of ontological concepts of the reference ontology that can be specified, according to the modelling primitives offered by the situational method and their conceptual alignment.

The degree of ontological completeness of a situational method can be defined as follows:

DoC = ( 1 - | OCn – OCs | ) / | OCn | where DC ∈ [0,1] This can be read as a percentage: “The situational method is (DC x 100) % ontologically complete.”

Therefore, OCn – OCs = ∅ “The situational method is ontologically complete” The same can be expressed as follows: DoC = 1 “The situational method is ontologically complete”


138

Figure 85. Examples of ontological completeness in terms of set theory.

Figure 85 shows several examples of OCn and OCs sets. The situational method is ontologically incomplete in cases a, b and c; the part of OCn which includes the ontological concepts that are not covered by the modelling techniques appears in dark grey. The situational method is ontologically complete in cases d and e.

3.2. Application of the proposal to a Method Engineering framework

Previous section introduces a generic approach to assess the ontological completeness of a situational method. This generic approach has three parameters:

• The project characteristics. Each project is started in a given situation and therefore it has certain characteristics.

• The reference ontology. This ontology is chosen depending on the application domain (which is determined by the situation). For instance, if the approach is to be applied in Computerised Information Systems development, then an ontology that addresses Information Systems should be chosen.

• The situational method. This is the method that is designed in order to enact it in the given situation.

The generic proposal needs to be formalised by applying it to a specific Method Engineering framework. Different frameworks for Situational Method Engineering are currently available. A priori, the proposal could be used with any of these frameworks. In this section, we use the framework presented by Mirbel and Ralyté [Mirbel and Ralyté 2005]. Their approach uses the notion of method chunks. Figure 86 shows a metamodel for modular methods. The authors consider the following definitions. The terms that appear in italics have their corresponding class in the metamodel.

• Method. A method is viewed as a chunk of the highest level of granularity. On its turn, a method is a set of loosely coupled method chunks expressed at different levels of granularity. A couple of two interrelated models: product model and process model.

o Product model. The product model of a method defines a set of concepts, relationships between these concepts and constraints for a corresponding schema construction.

o Process model. The process model describes how to construct the corresponding product model.


139

• Method chunk. An autonomous and coherent part of a method supporting the realisation of some specific ISD activities. Method chunk is composed of a descriptor, an interface and a body. A method chunk ensures a tight coupling of some process part of a method process model and its related product part.

o Descriptor. It extends the contextual view captured in the chunk interface to define the context in which the chunk can be reused. The descriptor takes values from the reuse frame and associates them to the corresponding method chunk.

o Interface. It captures the reuse context in which the method chunk can be applied. It is formalised by a couple <situation, intention>, which characterises the situation that is the input of the chunk process and the intention (the goal) that the chunk achieves.

Intention. A representation of the engineering goal to be achieved by applying the method chunk.

Situation. A parameter of the method chunk process that contains one or several product elements necessary to start its execution in order to achieve its intention.

o Method chunk body. The corresponding product and process parts constitute the body of the method chunk.

Product part. Specification of the product to be delivered by the method chunk.

Process part. Specification of the guidelines allowing to produce the product.

• Guideline. A statement or other indication of policy or procedure by which to determine a course of action [AHD 2000]. The guideline embodies method knowledge to guide the engineer in achieving an intention in a given situation; that is, to proceed in the construction of the target product.


140

GUIDELINE INTERFACE

SITUATION

INTENTION

PRODUCTPART

CHUNK NOT-CHUNK

AGGREGATE ATOMICDESCRIPTOR

1

1

HAS

METHOD1..*

2..*

1

1

HAS PROCESS MODEL

1..*

1..*

BELONGS TO

11 HAS

1..*

*

1..*

PRODUCTMODEL

1..*

1..*

IS BASED ON

1..*

1

IS BASED ON

1..*

*

TARGETOF

STRATEGIC GUIDELINE

TACTICAL GUIDELINE

SIMPLE GUIDELINE

ABSTRACTION LINK

NESTINGLINK

SEQUENCE

AND/OR LINK

COMPOSITION

CHOICE

1

*RELATES

1

2..*

1

2..**

RELATES 1

1

REPRESENTED BY

Figure 86. A metamodel for modular methods that uses the notion of method chunk

(adapted from [Mirbel and Ralyté 2005])

In order to support the evaluation of the ontological completeness of a situational method, the metamodel needs to be extended. The extension must include the metamodel corresponding to the project characteristics (situation of the method enactment) and the metamodel corresponding to the reference ontology. Regarding project characteristics, their metamodel can be expressed in a simplistic way, as Figure 87 shows. A given project has certain characteristics and enacts a situational method. This metamodel can be extended whenever a richer description of the project is needed.

Figure 87. Metamodel corresponding to the project characteristics

Regarding the reference ontology, the first issue to solve is the description of the ontology in terms of a class diagram. These diagrams are shown in Appendix A. The second issue is to metamodel the ontology. A simple metamodel that supports the description of the generic model of Information Systems is shown in Figure 88. In principle, the metamodel is descriptive enough to support other ontologies. However, if more expressiveness is needed to support a specific ontology, the metamodel can be extended.


141

Figure 88. Metamodel corresponding to the reference ontology

The reference ontology includes a set of interrelated ontological concepts. Each ontological concept is of one type. Ontological concepts can be basic concepts, a generalisation of other ontological concepts (a generalisation generalises ontological concepts of the same type), or an aggregation of other ontological concepts (an aggregation can aggregate ontological concepts of several types). Figure 89 shows the integration of the previous metamodels. The association ‘needs to be specified’ represents the SN mapping (see Figure 84 and related definitions); that is, the specification needs of the project situation. The association ‘is conceptually aligned to’ represents the CA mapping; that is SN represents the conceptual alignment of the situational method with respect to the reference ontology. In addition, a class named modelling primitive has been included to explicitly represent the modelling primitives that are included in the product part of a guideline.


142

Figure 89. Metamodel extended to include the reference ontology and the project

characteristics

The strategy to evaluate the degree of ontological completeness of a situational method has been explained in Section 3.1. It consists of calculating the difference between the ontological concepts that need to be specified in a given project situation and the ontological concepts that can actually be specified according to the designed situational method. The metamodel presented above can support this strategy. See Figure 90 for an overview of the strategy. The project is the pivotal class. Each project has certain characteristics that determine the specification


143

needs in terms of ontological concepts. This set of ontological concepts is referred to as OCn in Section 3.1. On the opposite sense, the project enacts a situational method (i.e. a situational method is designed for the project). This method is an assembly of method chunks. Each chunk has a product part that proposes a set f modelling primitives. The modelling primitives are conceptually aligned to ontological concepts. This set of ontological concepts is referred to as OCs in Section 3.1. The ontological completeness can be calculated by means of the difference of these two sets. Again, see Section 3.1 for the formulae.

ONTOLOGICAL CONCEPT

*

1IS CONCEPTUALLY ALIGNED TO

*

* NEEDS TO BE SPECIFIEDPROJECT

1

*

ENACTS MODELLING PRIMITIVE

GUIDELINE INTERFACE

SITUATION

INTENTION

PRODUCTPART

CHUNK NOT-CHUNK

AGGREGATE ATOMICDESCRIPTOR

1

1

HAS

METHOD1..*

2..*

1

1

HAS PROCESS MODEL

1..*

1..*

BELONGS TO

11 HAS

1..*

*

1..*

PRODUCTMODEL

1..*

1..*

IS BASED ON

1..*

1

IS BASED ON

1..*

*

TARGETOF

STRATEGIC GUIDELINE

TACTICAL GUIDELINE

SIMPLE GUIDELINE

ABSTRACTION LINK

NESTINGLINK

SEQUENCE

AND/OR LINK

COMPOSITION

CHOICE

1

*RELATES

1

2..*

1

2..**

RELATES 1

1

REPRESENTED BY

*

*

IS MODELLED BY MEANS OF

CHARAC-TERISTIC**

HAS

REFERENCE ONTOLOGY

GENERALI-SATION

BASIC

AGGRE-GATION

1..*

INCLUDES

RELATIONSHIP

*

1ORIGIN

*

1DESTINATION

RELATIONSHIP TYPE

ELEMENT TYPE *

1 IS OF TYPE

*

2

*

1 IS OF TYPE

*

2

*

*

*

1

*

*

*

*

DIFFERENCEOCn OCs

Figure 90. Strategy for evaluating the ontological completeness of a situational method


144

4. Further argumentation

Section V presents an approach for the evaluation of the ontological completeness of situational methods. The proposed approach in generic and can be implemented using one of the many frameworks for Method Engineering and one of the many ontologies that have been proposed over the years. The strategy has been applied to a framework for Method Engineering presented in [Mirbel and Ralyté 2005]. In this work, the generic model for Information Systems proposed in Section III has been used as a reference ontology because we consider it views Information Systems from a wide perspective. The Information Systems conceptual framework has been metamodelled in order to integrate it with the Method Engineering metamodel. We acknowledge that the ontology metamodel may need to be extended in order to use other ontologies (e.g. the BWW model). For instance, the Ontology Definition Metamodel [OMG 2007] proposed by the OMG could be used instead of the ontology metamodel shown in Figure 88. However, we decided to keep the metamodel simple in order to introduce the strategy for the ontological completeness evaluation. If the evaluation strategy is to be implemented, then the issue of which ontology metamodel to use has to be tackled with more care. Also, the product part related to every method chunk needs to be conceptually aligned to the reference ontology. This section presents an approach that should be considered at early stages of research; that is, further work is needed to consolidate it.

VI. Conclusions and future work

145

VI. CONCLUSIONS AND FUTURE WORK


146


147

1. Conclusions

This work started with the aim of offering deeper understanding about Information Systems and their underlying concepts. Also it intends to provide a means of evaluating software development methods from an ontological perspective. A look into the state of the art reveals that previous attempts have been made in both issues. However, ontologies and conceptual frameworks rarely address Information Systems social and communicational views. Both scientific realist and common-sense realist approaches fail to grasp the non-technological aspects of Information Systems; that is, these approaches focus only consider Information Systems to be a representation of the real world. However, the FRISCO report [Falkenberg, Hesse et al. 1998] presents a conceptual framework that takes into account the social view of Information Systems. FRISCO adopts a constructivist and semiotic approach to the matter. We share the same epistemological stance and we take FRISCO as a starting point. Instead of starting a conceptual framework from scratch, we adopt the FRISCO framework and we extend it with new concepts that are not present in the original proposal. A detailed framework of Information Systems concepts is offered in this work. The concepts related to communication have especial relevance. After all, we start with the idea that the Information System is a support to the communications of the Organisational System; these include the communication within the organisation and the communication between the organisation and the environment. Communication is considered to start after an event has occurred in the Subject System (i.e. the domain in which the organisation is interested). The event occurrence is reported to the Information System so that the organisation can react accordingly. The process of building the message that reports this occurrence is a complex mixture of actions. For communication to be possible, shared code and shared knowledge are needed. This way, a message needs to be edited according to certain rules that govern communication with the Information System. In order to allow and facilitate the editing of the message, both a linguistic and a metalinguistic context needs to be retrieved. The metalinguistic context mainly refers to the structure of the message, the format of its fields, any kind of aid in the editing and encoding of the input message, and error messages. The linguistic context refers to the domains of data fields and the factual feedback. These concepts regarding communication and message editing are defined in the conceptual framework and numerous examples are given to facilitate their understanding. The conceptual framework is a set of interrelated concepts. This framework is graphically depicted to allow a quick overview of the concepts and their relations. Also, the framework and its graphical representation constitute a generic model of a Information System. It is generic in the sense that it is not a model of a particular Information System (e.g. the Information System of the computer science department) but a model that abstracts the concepts underlying any Information System, especially if it is devoted to organisational management and operation. In one way or another, all the concepts of the generic Information System model appear in every Information System. In other words, we claim that the concepts presented in this work are useful for reasoning about Information Systems in general. Furthermore, the conceptual framework of Information Systems can be used to reason about software development methods, especially when the method is


148

intended to be enacted to computerise an Information System. An ontological evaluation technique called Conceptual Alignment is presented. It consists of defining mappings between the modelling techniques proposed by the software development method and the elements of the generic Information System model (a.k.a. ontological concepts). This way, the evaluator can assess which aspects of the Information System are covered by the modelling techniques of the method. Also, this evaluation can reveal certain ellipsis; that is, it can show which Information System elements are not being specified by the method. An ellipsis takes place whenever a modelling technique leaves out an ontological concept that is between two concepts which are taken into account. Also, the sequence of conceptual alignment diagrams shows in which order the method deals with the various aspects of Information Systems. In brief, conceptual alignment is the establishment of mappings between the concepts of the ontology and the modelling primitives. We encourage the Conceptual Modelling community to approach Ontology. The study of conceptual alignments helps to reason about the view of the world that underlies software development methods. Modelling techniques are used to describe reality and, therefore, they are based on some ontological preconceptions that should surface and be explicit. In this work, three software development methods have been conceptually aligned; namely, the Rational Unified Process, the WISDOM method, and the OO-Method. The conceptual alignment of these methods is accompanied by a case study that exemplifies the method and its modelling techniques. Conceptual alignment offers interesting insights into the concepts underlying the modelling primitives of a method. The initial hypotheses are confirmed:

• Developing a conceptual framework about Information Systems allows us to gain deeper knowledge about Information Systems. After all, the ISs conceptual framework contributes with new ideas and insights on the area (e.g. the identification of linguistic and metalinguistic context recovery as actions that occur in the IS interface).

• Developing a conceptual framework about Information Systems allows a better understanding of how Information Systems are computerised. After all, the ISs conceptual framework has been used to define a procedure for evaluating software production methods. This ontological analysis technique has been called conceptual alignment.


149

2. Future work

In future work, more software development methods and Information Systems modelling techniques will be conceptually aligned with respect to the generic Information System model. For instance, we plan to carry out the conceptual alignment of Tropos [Bresciani, Perini et al. 2004] (agent-oriented), Early Aspects-based approaches [Moreira, Rashid et al. 2005; Baniassad, Clements et al. 2006] and MAPS [Rolland 2007]. Also, we plan to carry out the conceptual alignment of other requirements elicitation techniques proposed by OO-Method that have not been considered in this work. For instance, this is the case of the business process-oriented approach [DeLaVara, Sánchez et al. 2008]. In the case of OO-Method and the RUP, we have detected the total ellipsis of the (external) communicational elements of the IS. Since this communicational ellipsis appears to be common, we plan to give descriptive support to the usage of communicational-oriented perspectives, based on Input and Output messages. Since many definitions describe Information Systems as a tool for communication we believe it to be a promising line of research. Among other research interests, we plan to integrate a model-based software development method (e.g. the OO-Method) and a method for Communication Analysis. A comparison among various methods will also help to better understand the concept of quality in conceptual modelling, following the tradition of well-known previous works such as [Lindland, Sindre et al. 1994]. This comparison will enable an enhancement of the criteria underlying well-established methods. We hope that a better integration among the various strategies will provide a holistic integration which will benefit the current state of Software Engineering. The Information Systems ontology that we are proposing could help the Conceptual Modelling community to revise their proposals. Our ultimate goal is to improve the quality of conceptual models. Our future work has this aim. Starting with a sound conceptual background, we aspire to reflect on commonly accepted techniques in order align their concepts and identify criteria of use. Our concern is to improve the quality of conceptual models. In this field, there is strong need of methodological experimentation to build an empirical base of knowledge. We are starting to drive methodological experiments both on learners and experts using different modelling techniques or even using the same modelling language but with different criteria. This research line is promising. For instance, we are conducting experiments that assess methodological criteria underlying use-case modelling techniques. We expect that the results of the experiments will help us to define better criteria for the tested techniques. Software Engineering should revise its foundations from time to time. Ontology and empirical studies play an important role in improving the quality in conceptual modelling. Also, we will tackle the limitations that have been acknowledged in this work. For instance, concepts regarding goals will be further analysed, we will consider the refinement of the IS reaction, we plan to offer a formal representation of the conceptual framework using some kind of logical grammar (e.g. sets algebra). We intend to validate the conceptual framework using the some kind of agreement procedure (e.g. the Delphi method). Also, the outcomes of the conceptual alignment will be summarised in tables as other authors do (Appendix B offers a draft of this tabular view).


150

VII. Appendices

151

VII. APPENDICES


152

A. Early versions of the generic IS model, using UML class diagram notation

This appendix gathers early models of the Information Systems conceptual framework using the class diagram notation. For the sake of simplicity, neither attributes nor methods are shown. Figure 91 shows a model that does not generalise message encoding actions.

Figure 91. A generic Information System model

Figure 92 clarifies the relations among the main types of concepts; namely, actors, actions and actands.

VII. Appendices

153

Figure 92. Class diagram showing the relations among the main types of concepts.

Figure 93 shows a model that generalises message encoding actions.

Figure 93. A more detailed generic Information System model


154

Figure 94 generalises message encoding actions. Now, the standard notation for specialisation is not used. Instead, a notation that takes advantage of topological inclusion is used (specialised classes are included inside more general classes).

ACTOREXTERNAL

ACTORINTERNAL ACTOR

INTERFACE PROCESSOR

REACTION PROCESSOR

ACTAND

EXTERNAL ACTAND

INPUT MESSAGE

OUTPUT MESSAGE

INTERNAL ACTAND

CONCEP. SCHEMA ELEMENT

INFORM. BASE

ENTITY

ENCODED OUTPUT

MESSAGE

ENCODED INPUT

MESSAGE

ACTION

EXTERNAL ACTION

FORMUL. INPUT

MESSAGE

INTERNAL ACTION

INTERPR. OUTPUT

MESSAGE

SYSTEM REACTION

ENCODING MESSAGE

ENCODING INPUT

MESSAGE

ENCODING OUTPUT

MESSAGE

actorOfactorOf actorOf

inputOfoutputOf outputOfinputOfoutputOf

inputOf inputOfoutputOfoutputOf inputOf

Figure 94. A generic Information System model using a non-standard specialisation notation

VII. Appendices

155

B. Summary of the OO-Method conceptual alignment

This appendix offers a draft of the tabular representation. The outcome of the ontological evaluation of the OO-Method is presented in a table.

Model view Modelling primitive Generic IS element (ontological concept)

Domain Model Class Information base update and reaction feedback x Information base entity(ies)

Agent class Interface processor Dynamic Model Class state Information base update and

reaction feedback Transition Information base update and

reaction feedback Functional Model Valuation Information base update and

reaction feedback Local transaction Information base update and

reaction feedback Global transaction Information base update and

reaction feedback Presentation Model Hierarchical actions

tree Localisation

Instance IU Coded output message Population IU Coded output message Service IU Coded input message Order criteria Metalinguistic context recovery Filter Linguistic context recovery Display set Metalinguistic context recovery Argument grouping Metalinguistic context recovery Dependency Metalinguistic context recovery Introduction Metalinguistic context recovery +

Linguistic context recovery Supplementary info Linguistic context recovery Defined selection Linguistic context recovery State recovery Linguistic context recovery Actions Localisation Navigation Localisation

Table 4. Summary of the OO-Method conceptual alignment outcome


156

C. Summary of BWW ontological concepts

Table 5 summarises the main constructs (ontological concepts) of the Bunge-Wand-Weber model (BWW model). This table is extracted from [Valverde and Toleman 2007]. In that work, the authors show how the ontological evaluation of business models (using the BWW model) can be used to compare them for equivalency of representation of business requirements.

BWW ontological concept

Definition

Thing The elementary unit in our ontological model. The real world is made up of things. A composite thing may be made up of other things (composite or primitive).

Property Things possess properties. A property is modelled via a function that maps the thing into some value. A property of a composite thing that belongs to a component thing is called a hereditary property. Otherwise it is called an emergent property. A property that is inherently a property of an individual thing is called an intrinsic property. A property that is meaningful only in the context of two or more things is called a mutual or relational property

State The vector of values for all property functions of a thing Conceivable State Space

The set of all states that the thing might ever assume.

State Law Restricts the values of the property functions of a thing to a subset that is deemed lawful because of natural laws or human laws

Event A change of state of a thing. It is effected via a transformation (see below).

Event Space The set of all possible events that con occur in the thing. Transformation A mapping from a domain comprising states to a

codomain comprising states. Process An intrinsically ordered sequence of events on, or state of,

a thing. Lawful Transformation

Defines which events in a thing are lawful.

History The chronologically ordered states that a thing traverses. Acts On A thing acts on another thing if its existence affects the

history of the other thing. Coupling A thing acts on another thing if its existence affects the

history of the other thing. The two things are said to be coupled or interact

System A set of things is a system if, for any bi-partitioning of the set, couplings exist among things in the two subsets.

VII. Appendices

157

BWW ontological concept

Definition

System Composition

The things in the system.

System Environment

Things that are not in the system but interact with things in the system.

System Structure The set of couplings that exist among things in the system and things in the environment of the system.

Subsystem A system whose composition and structure are subsets of the composition and structure of another system

System Decomposition

A set of subsystems such that every component in the System is either one of the subsystems in the decomposition or is included in the composition of one of the subsystems in the decomposition

Level Structure Defines a partial order over the subsystems in a decomposition to show which subsystems are components of other subsystems or the system itself

Stable State A state in which a thing, subsystem or system will remain unless forced to change by virtue of the action of a thing in the environment (an external event)

Unstable State A state that will be changed into another state by virtue of the action of transformation in the system..

External Event An event that arises in a thing, subsystem or system by virtue of the action of some thing in the environment on the thing, subsystem or system. The before-state of an external event is always stable. The after-state may be stable or unstable.

Internal Event An event that arises in a thing, subsystem, or system by virtue of lawful transformations in the thing, subsystem, or system. The before-state of an internal event is always unstable. The after state may be stable or unstable.

Well Defined Event An event in which the subsequent state can always be predicted given the prior state is known

Poorly Defined Event

An event in which the subsequent state cannot be predicted given the prior state is known. CLASS A set of things that possess a common property.

Kind A set of things that possess two or more common properties.

Table 5. Summary of ontological concepts from the BWW model


158

D. Summary of Chisholm’s ontological concepts

Table 6 summarises the ontological concepts of Chisholm’s common-sense ontology. The text has been extracted from [Milton and Kazmierczak 2004].

Chisholm’s ontological concept

Definition

Individual An individual is a discernable and transient object. It need not be material (or physical) in nature. Individuals are identified using attributes that only they exemplify, and may have constituents thereby giving them structure. This is called mereology [Honderich 1995]. Constituents may be other individuals (called parts) or may be boundaries (the other constituents). On the other hand spatial substances have boundaries. A boundary is a surface, line, or point. Boundaries of spatial substances are not of interest in data modelling.

Attribute An individual may exemplify attributes. Each attribute may be exemplified by many individuals. Some attributes may never be exemplified and others cannot be exemplified. If two attributes are considered to be equivalent then it is the case that where one attribute is exemplified by an individual then so is the other. This is called conceptual entailment in the ontology. Chisholm allows for compound attributes, which in turn may consist of other compound attributes or simple attributes. He suggests that an attribute may be the conjunction or disjunction of several attributes. Chisholm also indicates that there may be alternative mechanisms for providing compound attributes, other than conjunction and disjunction. Philosophically and logically it makes little sense to talk about when an attribute came into being. In Chisholm’s ontology, attributes are enduring, thus avoiding the problem of declaring when an attribute comes into being.

Classification Classes and sets may be part of a state-of-affairs. In Chisholm’s ontology, attributes are used to restrict membership of sets and classes. Indeed, Chisholm’s ontology reduces the discussion of classes to the discussion of attributes by adopting Russell’s reduction of classes to attributes [Russell 1908]. This has the effect of building classes and sets from individuals through the exemplification of an individual’s attributes and not by constructing elaborate class structures. For example, suppose we are maintaining a taxonomy of plants. Periodically, the taxonomy may change quite drastically without a change in the majority of attributes exhibited by

VII. Appendices

159

Chisholm’s ontological concept

Definition

the plants involved. Using Chisholm’s ontology classes can change radically through a change in membership criteria based on attribute exemplification. Classes and sets can be selected based upon attributes that are conjunctions and disjunctions of other attributes, and in this sense complex class relationships can be realised, that are essentially class structures. The central point remains that individuals come together to form classes and are fundamental to the ontology. Classes are reflections of attributes exemplified by individuals due to the fact that they exemplify the attributes that are used to select the class.

Relation Chisholm’s ontology allows for relations between individuals. Chisholm says: “To know what relations are, we must understand the concept of the direction of relations.” [Chisholm 1996] Chisholm means that relations may not be reciprocated, or alternatively must be carefully considered from the viewpoints of all individuals concerned. It is for this reason that relations are unidirectional. Further, in the ontology, relations are be represented by ordered pairs of identifying individuals. This comes from the fact that ordered pairs are related to sets of a specific form and therefore can be reduced to a discussion of attributes in the manner noted above. Therefore relations, despite being needed to describe a state-of-affairs, do not constitute a separate fundamental category but instead are related to attribute. For an ordered pair to represent unidirectional relations, attributes need to be found that uniquely describe and thereby identify each individual. In the simplest case an individual may be related to another (binary). More complex relations between three individuals (ternary) or more (n-ary) are allowed. Mathematically it is proven that these all can be reduced to a series of binary relations [Quine 1960].

Table 6. Summary of ontological concepts from Chisholm’s ontology


160

E. Summary of FRISCO ontological concepts

Table 7 summarises FRISCO ontological concepts. This table is extracted from the glossary at the end of the FRISCO report [Falkenberg, Hesse et al. 1998]. The following conventions are used in the glossary:

• Glossary entry in bold: A defined concept. Some concepts include synonyms and related terms (Also).

• Term in bold: A concept defined in this glossary entry • Term underlined: A concept defined in another glossary entry • The numbering [En] refers to the explanatory definitions in chapter 3 of the

FRISCO report, and the numbering [Pn], [Dn] or [Fn] refers to the primitives, definitions or functions in chapter 4 of the FRISCO report, respectively.

FRISCO ontological concept

Definition

Absolute time [E11, D14]

Absolute time may be determined by a clock that issues (assumedly) regular pulses (transition occurrences of the clock, or clock events). An absolute time value may be assigned to some transition occurrence, by comparing that transition occurrence with the successive (absolute-time-determining) clock events. A strictly ordered set of time points can be defined on the basis of these clock events, called time axis.

Actand [E15, D20] An actand is a thing involved in the pre-state or post-state of an action, not considered as an actor for that action. Also Object of action

Action [E14, D17]

An action is a transition involving a non-empty set of actors in its pre-state, and, if not "destroyed" or "consumed" by the action, in its post-state as well, and involving a non-empty or empty set of other things (actands) as part of its pre–state, and having a non-empty or empty set of other things (actands) in its post– state. Also referred as Act, Activity

Action context [E16, P5, D22]

The action context of an action is a special, optional part of the pre-state of that action, qualifying the context or situation in which that action is performed, and determining or modifying at least one of its output actands.

Action occurrence [E14]

An action occurrence is a transition occurrence with the same conditions as applying for the notion of action.

Active system [E31, D43]

An active system is conceived as capable of doing something, i.e. some of the system components are actors performing actions on actands.

Actor [E13, P4, D19]

An actor is a special thing conceived as being "responsible" or "responsive" and as being able to "cause"

VII. Appendices

161


Definition

transitions, and is therefore part of their pre-states, and, if not "destroyed" or "consumed" by the transitions, also part of their post-states.

Alphabet [E22, D28] An alphabet of a language is a non-empty and finite set of symbols.

Closed System [E31, D44]

A system is called a closed system if the system environment cannot cause any transitions within the system.

Co-action [E14]

A co-action is a special action performed by more than one actor in a co-ordinated way, pursuing a common goal.Also Co-ordinated action

Communication [E37, D37]

Communication is an exchange of messages, i.e. a sequence of mutual and alternating message transfers between at least two human actors, called communication partners, whereby these messages represent some knowledge and are expressed in languages understood by all communication partners, and whereby some amount of knowledge about the domain of communication and about the action context and the goal of the communication is made present in all communication partners.

Composite action [E14, D18]

A composite action is a composite transition with the same conditions as applying for the notion of action.

Composite thing [E4, D7]

A composite thing is a thing, not being an elementary thing. Also Aggregate, Collection of things, Set of things

Composite transition [E9, D11]

A composite transition is a state-transition structure with a unique pre-state and a unique post-state.

Computerised information sub-system (CISS) [E41, D49]

A computerised information sub-system is a sub-system of an information system, whereby all actions within that sub-system are performed by one or several computer(s). Also Information system in the narrow sense

Conceiver [E20, D26]

A conceiver is a human actor involved in a conceiving action.

Conceiving action [E20, D26]

A conceiving action is a special action of a human actor having a perception and possibly some action context as input actand(s) and a conception as output actand.

Conceiving context [E20, D26]

A conceiving context is the action context of a conceiving action.

Conception [E20, P10, D26]

A conception is a special actand resulting from an action whereby a human actor aims at interpreting a perception in his mind, possibly in a specific action context.

Data [E34, D34] The term data denotes any set of representations of knowledge, expressed in a language.

Domain [E18, P8, D25]

A domain comprises any "part" or "aspect" of the "world" under consideration. Also Area, Field, Universe of discourse


162


Definition

Domain component [E18]

A domain component is any "part" or "aspect" of that domain. Also Domain element

Domain environment [E18]

A domain environment is the "world" without that domain.

Dynamic system [E31, D42]

A dynamic system is conceived as capable of undergoing change, i.e. some of the system components are transitions.

Elementary thing [E4, D5]

An elementary thing is a thing, not being a relationship and not being characterised by the special predicator called 'has-element'.

Entity [E5, D6]

An entity is a predicated thing as well as an elementary thing.

Extensional model [E28]

An extensional model is that part of a model containing a specific population of the types in the corresponding intensional model, whereby this population must obey all rules determined in that intensional model.

Goal [E17, P6, D23]

The goal of an action is a special input actand of that action, pursued by the actors of that action and stating the desired output state intensionally.

Goal-pursuing actor [E17]

A goal-pursuing actor is an actor performing an action, who deliberately aims at a specific goal when involved in that action.

Human actor [E19, P7, D24]

A human actor is a responsible actor with the capabilities and liabilities of a normal human being, in particular capable of performing perceiving actions, conceiving actions and representing actions.

Information [E36, D36]

Information is the personal knowledge increment brought about by a receiving action in a message transfer, i.e. it is the difference between the conceptions interpreted from a received message and the personal knowledge before the receiving action.

Information system [E40, D47]

An information system is a sub-system of an organisational system, comprising the conception of how the communication- and information-oriented aspects of an organisation are composed (e.g. of specific communicating, information-providing and/or information-seeking actors, and of specific information-oriented actands) and how these operate, thus describing the (explicit and/or implicit) communication-oriented and information–providing actions and arrangements existing within that organisation. Also Information system in the broad sense

Information system denotation [E40]

An information system denotation is a precise and unambiguous representation of an information system.

Input actand [E15, F8]

An input actand is a part of the pre-state of an action, excluding the actors.

Instance [E6, D15] An instance of a type of things is an element of a

VII. Appendices

163


Definition

population of that type. Intensional model [E28]

An intensional model is that part of a model comprising the possibilities and necessities of a domain only, i.e. the types and rules.

Interpreter [E21, D27]

An interpreter is a human actor performing an interpreting action.

Interpreting action [E21, D27]

An interpreting action is the sequence of a perceiving action performed on a domain, resulting in a perception of that domain, followed by a conceiving action performed on that perception, resulting in a conception. Also Interpreting process

Interpreting context [E21, D27]

An interpreting context is the action context of an interpreting action.

Knowledge [E33, F11, D33]

Knowledge is a relatively stable and sufficiently consistent set of conceptions possessed by single human actors. Also Personal knowledge

Label [E24, D29] A label is a special entity being an elementary representation and used for referring to some conception in an elementary way. Also Elementary sign, Name

Language [E22, D28]

A language is a non-empty set of permissible symbolic constructs. The permissible symbolic constructs in a language are determined either extensionally by enumeration or intensionally by a set of rules. The rules of a language may be syntactic ("grammar") as well as semantic ("semantic rules").

Message [E35, D35]

A message is data, transmitted by one actor (the sender) via a channel (a medium), and intended for a nonempty set of other actors (the receivers).

Message transfer [E35, P14, D35]

A message transfer is a sequence of actions, the sending action by the sender and the receiving actions by the receivers, whereby the input actand of the sending action is the message to be sent, whereby the output actand of the sending action, being equal to the input actand of the receiving action, is the message on the channel, and whereby the output actand of the receiving action is the message received.

Meta-model [E29]

A meta-model is a model of the conceptual foundation of a language, consisting of a set of basic concepts, and a set of rules determining the set of possible models denotable in that language.

Model [E26, P13, D30]

A model is a purposely abstracted, clear, precise and unambiguous conception.

Model denotation [E26, D31]

A model denotation is a precise and unambiguous representation of a model, in some appropriate formal or semi-formal language.

Modeller [E27, D32] A modeller is a human actor performing a modelling


164


Definition

action. Modelling action [E27, D32]

A modelling action is the sequence of a perceiving action performed on some domain, followed by a conceiving action on that perception, resulting in a model, and followed by a representing action on that model, resulting in a model denotation. Also Modelling process

Norm [E39]

Norms are socially agreed rules affecting and to a large extent directing the actions within an organisational system.

Open system [E31, D44]

An open system is conceived as one which may respond to external messages or triggers, i.e. there may be transitions within the system due external causes coming from the system environment.

Organisational system [E39, D45]

An organisational system is a special kind of system, being normally dynamic, active and open, and comprising the conception of how an organisation is composed (i.e. of specific actors and actands) and how it operates (i.e. performing specific actions in pursuit of organisational goals, guided by organisational rules and informed by internal and external communication), where its systemic properties are that it responds to (certain kinds of) changes caused by the system environment and, itself, causes (certain kinds of) changes in the system environment.

Output actand [E15, F9]

An output actand is a part of the post-state of an action, excluding the actors.

Passive System [E31, D43]

A system is called a passive system if it is not active.

Perceiver [E19, D25]

A perceiver is a human actor involved in a perceiving action.

Perceiving action [E19, D25]

A perceiving action is a special action of a human actor having a domain as input actand and a perception as output actand.

Perception [E19, P9, D25]

A perception is a special actand resulting from an action whereby a human actor observes a domain with his senses, and forms a specific (static, non-time-varying, or dynamic, time-varying) pattern of visual, auditory or other sensations of it in his mind.

Population [E6, D15]

A population of a type of things is a set of things, each one fulfilling the characterisation determining that type.

Post-state [E7, F6] The post-state of a transition is the state valid after that transition, and is characterised by the special predicator 'after'.

Pre-state [E7, F5] The pre-state of a transition is the state valid before that transition, and is characterised by the special predicator 'before'.

Predicated thing A predicated thing is a thing being characterised or

VII. Appendices

165


Definition

[E2, D3] qualified by at least one predicator. Predicator [E2, D2] A predicator is a thing, used to characterise or qualify

other things, and assumed as being "atomic", "undividable" or "elementary". Also Qualifier, Role

Receiver [E35, D35] A receiver is an actor receiving a message. Reference [E24, P12, D29]

A reference is a special binary relationship between a conception and a representation used to describe that conception. Also Sign relationship

Relationship [E3, D1]

A relationship is a special thing composed of one or several predicated thing(s), each one associated with one predicator characterising the role of that predicated thing within that relationship.

Relative time [E11, D13]

The strict partial order imposed on the sets of all transition occurrences is called relative time.

Representation [E23, P11, D28]

A representation is a special actand describing some conception(s) in a language, resulting from an action whereby a human actor aims at describing his conception(s), possibly in a specific action context. Also Representamen, Sign, Sign carrier, Sign token, Signifiant

Representer [E23, D29]

A representer is a human actor involved in a representing action.

Representing action [E23, D29]

A representing action is a special action of a human actor having a conception and possibly some action context as input actand(s) and a representation as output actand.

Representing context [E23, D29]

A representing context is the action context of a representing action.

Resource [E15, D21]

The pre-state of an action, i.e. the union of the set of actors and the set of input actands of that action, is called its resources.

Rule [E12, D16]

A rule determines a set of permissible states and transitions in a specific context. In other terms, a rule governs a non-empty set of types of things by determining their permissible populations. Also Law

Semiotic level [E25]

The semiotic level of a representation is the aspect considered in representing it. The semiotic levels are: physical, empirical, syntactical, semantical, pragmatic, and social.

Sender [E35, D35] A sender is an actor sending a message. Set membership [E4, P2, D4]

A set membership is a special binary relationship between a thing (the set), characterised by the special predicator called 'has-element', and another thing, characterised by the special predicator called 'is-elementof'.


166


Definition

Shared knowledge [E38, D38]

Shared knowledge is that knowledge of the individuals in a group of human actors, which they assume to be identical (or at least similar) to that of the others, as resulting from the negotiation process implicit in some communication.

State [E7, D9]

A state is a composite thing, involved as pre-state or as post-state in some transition. No element of a state may be a transition, itself.

State-transition structure [E8, D10]

Given are the transitions tx: s1 => s2 and ty: s3 => s4. The following basic state-transition structures exist in this case: (1) Sequence: sequ (tx, ty) is a sequence of transitions if s3 is a subset of s2. The resulting state-transition structure has s1 as pre-state and s4 as post-state. Longer sequences are defined as follows: sequ (tx, ty, tz) follows from sequ (tx, ty) and sequ (ty, tz) (2) Choice: choice (tx, ty) is a choice of transitions if the intersection of s1 and s3 is not empty. The result is either transition tx or ty, but not both. (3) Concurrency: concur (tx, ty) are concurrent transitions if the intersection of s1 and s3 is empty. The result is (s1 union s3) => (s2 union s4). Also Process

Static system [E31, D42]

A system that is not dynamic is called a static system.

Sub-system [E32, D41]

Any sub-system S' of a larger system S is a system, itself. The set of all sub-system components of S' is a proper subset of the set of all system components of S.

Symbol [E22, D28]

A symbol is a special entity used as an undividable element of a representation in a language.

Symbolic construct [E22, D28]

A symbolic construct is a non-empty and finite "arrangement" of symbols taken from an alphabet. In the one-dimensional case, an arrangement is just a sequence of symbols (a "sentence"). In the n-dimensional case (n>1), it may be any arrangement of its constituting symbols in the n-dimensional space. Provided one considers the elements of arrangement (such as sequence) belonging to the alphabet, a symbolic construct is a non-empty and finite set of symbols. Also Symbolic form

System [E30, D40]

A system is a special model, whereby all the things contained in that model (all the system components) are transitively coherent, i.e. all of them are directly or indirectly related to each other form a coherent whole. A system is conceived as having assigned to it, as a whole,

VII. Appendices

167


Definition

a specific characterisation (the so-called "systemic properties") which cannot be attributed to any of its system components.

System component [E30]

A system component is a non-empty set of things being contained in that system. Also System element

System denotation [E30]

A system denotation is a precise and unambiguous representation of a system.

System environment [E30]

The system environment of a system is the set of all things not being contained in that system.

System representer [E30]

A system representer is a human actor representing a system in some language.

System viewer [E30]

A system viewer is a human actor perceiving and conceiving a domain as a system. A system viewer recognises the system, by its distinction from the system environment, by its coherence, and because of its systemic properties.

Thing [E1, P1]

A thing is any part of a conception of a domain (being itself a "part" or "aspect" of the "world"). The set of all things under consideration is the conception of that domain. Also Object

Transition [E7, P3, D8]

A transition is a special binary relationship between two (partially or totally) different composite things, called the pre-state and the post-state of that transition, whereby at least one thing is element of the prestate, but not of the post-state, or vice versa.

Transition occurrence [E10, D12]

A transition occurrence is a specific occurrence of a transition. A set of transition occurrences is subject to strict partial ordering. Also Event

Type [E6, D15] A type of things is a specific characterisation (e.g. a predicate) applying to all things of that type. Also Category

Table 7. Summary of ontological concepts from the FRISCO report


168

F. A technique to model interaction requirements in the OO-Method

This appendix proposes a method for capturing interaction requirements in an MDA environment. Following ISO 9126-1 [ISO/IEC 2001], usability is a software characteristic that strongly influences software quality. Usability is related to modelling and implementing interaction according to user requests. Therefore, a requirements model to formally capture user interaction requests is appropriate. The technique that the OO-Method proposes for capturing interaction requirements is based on Paternò’s ConcurTaskTrees (CTT) [Paternò, Mancini et al. 1997]. The original grammar is extended to suit the OO-Method. This grammar has the following layers:

• Lexical. This is provided by CTT notation (interaction tasks, system tasks, and abstract tasks).

• Syntactic. This is made up of structural task patterns that are structures of tasks related to each other by means of temporal operators.

• Semantic. This is provided by the correspondence between task patterns and Model Presentation patterns of the OO-Method.

Structural task patterns have been defined generically. Therefore, they offer arguments that are instantiated when patterns are used to model a specific interface. In the following figures, these arguments are shown in italics format, indicating that their names and values should be instantiated. Arguments with variable cardinality are represented with ellipses (i.e., 1..N). However, manual construction of these structural task patterns is very difficult, even though there is a tool to support the drawing thereof. Moreover, for small applications, the structural task patterns become illegible due to the huge number of CTTs that are created. This paper proposes a different abstraction level to represent the interface by means of sketches. The analyst, with the help of the user, draws sketches that represent the final interfaces. As the sketches are drawn, the structural task patterns are built automatically. Sketches are an early model to represent the user interface. In order to define a new model, the first step is to establish a set of basic builders. In other words, the primitives for building up a sketch to represent the interface should be defined. The CTTs are built at the same time that the sketches are drawn. The second step is then to define a biunivocal relationship between sketch primitives and structural task patterns. For each structural task pattern, a sketch primitive is defined. Therefore there are two models to represent system interaction, in other words, two pieces of the jigsaw puzzle to represent the interaction. On the one hand, CTTs have the advantage of being a formal language. A formal language provides a formal semantic, makes the model verifiable, and avoids ambiguity in specification. On the other hand, sketches are very simple. Therefore they are easy to create and can be understood by the final user. For the sake of brevity, this appendix focuses on the structural task patterns related to a list of instances (Population IU and its related Elementary Patterns)

VII. Appendices

169

Figure 95. Graphical primitive and structural task pattern for Filter

Filter primitives for sketches specify a filter criterion for the listed instances in the population. The analyst must place a symbol above the columns that the user wants to use in the filter (the letter F in Figure 95). These marked columns instantiate the arguments of the corresponding structural task pattern.

Figure 96. Graphical primitive and structural task pattern for Order criteria

The Order criteria pattern is defined in a manner similar to the Filter primitive. Some symbols are placed above the columns (the letter O in Figure 96) to order the listed instances. These symbols provide values for the arguments of the pattern.

Figure 97. Graphical primitive and structural task pattern for Actions

Actions, shown in Figure 97, represent operations that can be made with the selected instance in the population list. Some actions are very common (i.e., create a new instance, modify it, or delete it); others are specific to the system that is being sketched. Actions instantiate the arguments of the structural task pattern.


170

Figure 98. Graphical primitive and structural task pattern for Navigation

Navigation is related to ‘travelling’ from one part of the interface to another. The analyst draws the navigation to system interfaces that implement queries or editions of objects related to the object source (Figure 98). For example, starting from an invoice line list, the user can navigate to the client data. The set of possible destinations builds the arguments of this pattern. Once the arguments are built, the system task is in charge of carrying out the navigation.

Figure 99. Graphical primitive and structural task pattern for Display set

The Display set primitive (Figure 99) specifies the columns of the population instances that will be shown graphically. This primitive is a set of columns that the analyst can assign a name to. The names of the columns inserted in the sketch provide the values of the structural task pattern arguments. Once the correspondences between the structural task patterns and the third level of the Presentation Model patterns [Molina 2003] are defined, the next step is to do the same with the second level of the Presentation Model patterns.

Figure 100. Graphical primitive for Population

VII. Appendices

171

The Population primitive presents to the user a list of instances from a business object class (i.e., a list of customers). As Figure 100 shows, it may include all the primitives that represent elements of the third level in the OO-Method Presentation Model through structural task patterns. Figure 7 presents the corresponding structural task pattern. The numbers in circles show the common parts.

Figure 101. Population with CTT notation

As Figure 101 shows, the CTT that represents the population pattern includes interaction tasks that are in charge of filtering (Filter) and arranging (Order) the instances. The brackets represent grammatical-composition rules. In other words, they are points at which to hook the leaves to other structural task patterns. A system task is then used to show the instances of the objects (Display), which are filtered and ordered by the selected criteria on the screen. Finally, the user can carry out Action and Navigation operations with these instances, which are represented in the diagram by means of abstract tasks. All of these structural task patterns can be composed to model the interaction with a list of instances.

Further comments on using task-tree notations Task analysis is a widely accepted practice in Human-Computer Interaction and is at the core of many of the software development methods proposed by this community. Limbourg and Vanderdonckt [Limbourg and Vanderdonckt 2004] identify three related poles involved in task analysis: task models, task analysis methods, and support tools. In the following, we will discuss how our proposal deals with these three poles. In the first pole of task analysis, models are descriptions of the world that capture some facets of a problem. ConcurTaskTrees (CTT) is a modelling language developed by Paternò [Paternò, Mancini et al. 1997]. CTT models are used to describe how people perform the tasks they undertake. Tasks are hierarchically decomposed to the level of basic tasks, which are defined as tasks that should not be further decomposed. The second pole appears in this stage because a stepwise approach is required. Several questions arise at this point of the method. What is the correct granularity for tasks? Since the criterion for starting and stopping task decomposition is sometimes fuzzy, we took some arbitrary but useful decisions. A task tree is built for every use case that has appeared in functional


172

requirements elicitation; therefore, the granularity of the root task of our task models is a use case. The use cases are built before the interaction requirements are captured. Whether the use cases technique offer useful criteria for their granularity falls off the scope of this work; we are just dealing with interaction requirements. A set of structural patterns has been fixed and, thus, we offer guidance by limiting the degrees of freedom that the analyst has to create the model. Even more, we propose to stop decomposing at the level of basic data elements that are to be communicated between the user and the information system. Is a hierarchical decomposition appropriate for dealing with tasks? As Diaper acknowledges in [Diaper and Stanton 2003], it is often argued that much of the natural world is not truly hierarchical and would be better modelled as a heterarchy, allowing a more flexible mereology. This concern is better understood if one asks the following question. Do task trees model the interface or the interaction? Both intentions are not the same; Figure 102 shows the difference between identifying interface components in order to make a description of the interface (Figure 102.a) and identifying a path through the interface so as to describe a particular interaction with that interface (Figure 102.b). Of course, both types of descriptions involve specifying further details and interaction descriptions also address issues which are not directly related to the software application (e.g. user tasks in which the user makes decisions and carries out other physical or mental tasks on its own).

a) Identifying interface components for an interface description

b) Identifying a path through the interface for an interaction description

Saturday, 04 November 2007

Saturday, 04 November 2007

4355

4355

Figure 102. The difference between interface and interaction description

Interface windows and screens can be effectively described in terms of a component tree whereas navigation needs cyclic graphs. Task trees are closer to interaction modelling, although temporal operators offer the possibility of simultaneously describing many of the possible paths through an interface (i.e., using the [ ] operator). A problem appears when trying to specify navigation in CTT models.

VII. Appendices

173

Subtask B2

Do task B

|||

Subtask B1

Interaction B

Subtask A2

Do task A

Subtask A1

|||

Interaction A

Figure 103. Example of two tasks using the CTT notation

Suppose two tasks (Interaction A and Interaction B) that have access to each other. Figure 103 shows both tasks without considering any navigation. Figure 104 shows two solutions that describe this requirement. Figure 104.a includes Interaction B as a subtask of Interaction A and then closes a loop by drawing an explicit link between Interaction B and Interaction A; this diagram violates the notation because it is not a tree anymore. Figure 104.b reitalicsly includes each task inside the other one; although this solution complies with the notation, it produces trees of infinite depth.

Figure 104. Two inappropriate ways of dealing with navigation in CTT models

To overcome this problem, we have defined an implicit semantics for those tasks dealing with navigation. Figure 105 shows a solution to the above mentioned requirement of navigation between Interaction A and Interaction B by creating two task trees and using implicit navigational semantics (the dashed arrows which show the destiny of the navigation are merely informative and would not be part of the model).


174

Even if navigation is properly addressed, two more questions arise: Are the resulting task trees manageable in big projects? Can task trees be reused? The structural pattern approach is a stepwise approach to task modelling and offers an additional advantage: it allows the reuse of the structural task patterns by defining connection points. Note that each structural task pattern defines a male-plug connection point of the form <pattern type> (see the Figures 95-101). Some of the structural task patterns include socket-like connection points of the form <<pattern type>> (see Figure 101); structural task patterns of the appropriate type can be attached to these connection points (those that define the corresponding male-plug connection point). For example, an Actions structural task pattern (see Figure 97) would be attached to the <<Actions>> abstract task of a Population structural task pattern (see Figure 101). This composition mechanism is our extension to the CTT syntactic layer. It allows structural task patterns to be reused.

Figure 105. Navigation modelled by implicit semantics

However, the above-mentioned concerns are also related to the third pole of task analysis; that is, tool support. We conceive of a task model repository that allows to store and reuse structural task patterns. Furthermore, we have introduced an approach to interaction modelling based on sketches. If task models are transparent to the analyst, they are definitely manageable. A set of equivalences between sketching primitives and structural task patterns allows the synchronic construction of sketches and task models. The analyst deals with sketches, which are understandable by the user; the CTT layer ensures correctness and unambiguity, as well as it serves as a formal basis for the transformations that derive part of the Presentation Model (the abstract interface model which is a view of the OO-Method Conceptual Model). The CTT modelling language also allows specifying actions and objects for each basic task, where objects could be perceivable objects (interactors) or application objects and actions define how these objects are manipulated by the task. In our approach, these aspects need not be explicitly specified. The perceivable objects are the interface components represented in the sketch. The correspondence between sketching primitives and structural task trees already fixes the task-object relationship. The actions are implicitly stated by the semantics of each part of the structural task tree. For example, each of the fields of a Display pattern (see Figure 99) has an associated output action.

VIII. References

175

VIII. REFERENCES


176

VIII. References

177

Ågerfalk, P. J. and B. Fitzgerald (2006). Exploring the concept of method rationale: A conceptual tool for method tailoring. Advanced Topics in Database Research. Vol 5. K. Siau (ed.). Hershey, PA., Idea Group.

Ågerfalk, P. J. and J. Ralyté (2006). Situational Requirements Engineering Processes: reflecting on method engineering and requirements practice. Software Process: Improvement and Practice., Wiley.

AHD (2000). The American Heritage Dictionary of the English Language, Houghton Mifflin Company.

Baniassad, E., P. C. Clements, et al. (2006). "Discovering Early Aspects." IEEE Softw. 23(1): 61-70.

Barchini, G., M. Álvarez, et al. (2007). "El rol de las ontologías en los SI." Revista Ingeniería Informática 14.

Bodart, F. and J. Vanderdonckt (1996). Widget standarisation through Abstract Interaction Objects. Proc. of 1st Int. Conf. on Applied Ergonomics ICAE'96, USA Publishing: 300-305.

Booch, G., J. Rumbaugh, et al. (1999). The Unified Modeling Languge, Addison-Wesley.

Braun, H. v., W. Hesse, et al. (2000). Conceptions are Social Constructs - towards a Solid Foundation of the FRISCO Approach. Proceedings of the IFIP TC8/WG8.1 International Conference on Information System Concepts: An Integrated Discipline Emerging, Kluwer, B.V.: 61-73.

Bresciani, P., A. Perini, et al. (2004). "Tropos: An Agent-Oriented Software Development Methodology." Autonomous Agents and Multi-Agent Systems 8(3): 203-236.

Brinkkemper, S. (1996). "Method engineering: engineering of Information Systems development methods and tools." Information and Software Technology 38(4): 275-280.

Brinkkemper, S., M. Saeki, et al. (1999). "Metamodelling based assembly techniques for situational method engineering." Inf. Syst. J. 24(3): 209-228.

Bubenko, J. A. (1980). Information modeling in the context of system development. IFIP Congress 1980, Tokyo, Japan, North-Holland.

Bunge, M. (1977). Treatise on Basic Philosophy. Vol III. Ontology I: The Furniture of the World. Dordrecht, The Netherlands, Reidel.

Bunge, M. (1979). Treatise on Basic Philosophy. Vol IV. Ontology II: A World of Systems. Dordrecht, The Netherlands, Reidel.


178

Canfora, G., A. Cimitile, et al. (1995). "Assessing modularization and code scavenging techniques." Journal of Software Maintenance: Research and Practice 7(5): 317-331.

Ceri, S., P. Fraternali, et al. (2000). Web Modeling Language (WebML): a modeling language for designing Web sites. 9th international World Wide Web conference on Computer networks (WWW9). Amsterdam, The Netherlands, North-Holland Publishing Co.: 137-157.

Colomb, R. M. and R. Weber (1998). Completeness and quality of an ontology for an Information System. International Conference on Formal Ontology in Information Systems (FOIS'98). N. Guarino (ed.). Trento, Italy, IOS-Press: 207-217.

Constantine, L. L. and L. A. D. Lockwood (1999). Software for use: a practical guide to the models and methods of usage-centered design. Reading, USA, ACM Press/Addison-Wesley Publishing Co.

Chen, P. P.-S. (1976). "The entity-relationship model—toward a unified view of data." ACM Trans. Database Syst. 1(1): 9-36.

Chisholm, R. M. (1996). A realistic theory of categories: an essay on Ontology, Cambridge University Press.

Davies, I. G., P. F. Green, et al. (2003). Using meta models for the comparison of ontologies. Evaluation of Modeling Methods in Systems Analysis and Design Workshop (EMMSAD'03), in Eighth CAiSE/IFIP8.1, Klagenfurt/Velden, Austria.

Dayton, T., J. Kramer, et al. (1996). Participatory GUI design from task models Conference companion on Human factors in computing systems: common ground Vancouver, British Columbia, Canada ACM Press: 375-376

DeLaVara, J. L. and J. Sánchez (2007). Business process-driven requirements engineering: a goal-based approach. 8th Workshop on Business Process Modeling, Development, and Support (BPMDS'07), 19th International Conference on Advanced Information Systems Engineering (CAiSE'07), Trondheim, Norway.

DeLaVara, J. L., J. Sánchez, et al. (2008). Business process modelling and purpose analysis for requirements analysis of information systems. 20th International Conference on Advanced Information Systems Engineering (CAiSE'08), Montpellier, France, LNCS, Springer (to be published).

Diaper, D. and N. Stanton, Eds. (2003). The handbook of task analysis for Human-Computer Interaction, Lawrence Erlbaum Associates.

Díaz, I., F. Losavio, et al. (2004). "A specification pattern for use cases." Information and Management 41(8): 961-975.

VIII. References

179

España, S. (2007). Conceptual alignment of software production methods. Departamento de Sistemas Informáticos y Computación, Universidad Politécnica de Valencia

Falkenberg, E., W. Hesse, et al. (1998). FRISCO. A Framework of Information Systems Concepts (IFIP WG 8.1 Task Group Report)

Fiedler, F. E. (1964). "A contingency model of leadership effectiveness." Advances in Experimental Social Psychology 1: 149-190.

Fitzgerald, G. (1991). Validating new information systems techniques: a retrospective analysis. Information Systems research: contemporary approaches and emergent traditions. H. E. Nissen, H. K. Klein and R. Hirschheim (ed.). Amsterdam, Elsevier Science Publishers B.V: 657-672.

Fox, M. S. and M. Gruninger (1998). "Enterprise modeling." AI Magazine Fall 1998.

Gregersen, H. and C. S. Jensen (1999). On the Ontological Expressiveness of Temporal Extensions to the Entity-Relationship Model. Proceedings of the Workshops on Evolution and Change in Data Management, Reverse Engineering in Information Systems, and the World Wide Web and Conceptual Modeling, Springer-Verlag.

Grenon, P. (2003). Nuts in BFO's nutshell: Revisions to the bi-categorial axiomatization of BFO (IFOMIS Reports 07/2003) http://www.ifomis.uni-saarland.de/Research/IFOMISReports/IFOMIS%20Report%2007_2003.pdf, Accessed 02-2007.

Gruber, T. (1995). "Toward Principles for the Design of Ontologies Used for Knowledge Sharing." International Journal Human-Computer Studies 43(5-6): 907-928.

Grüninger, M. and J. Lee (2002). "Ontology applications and design." Commun. ACM 45(2): 39-41.

Guarino, N. (1995). "Formal ontology, conceptual analysis and knowledge representation." International Journal of Human-Computer Studies 43(5-6): 625-640.

Guarino, N. (1998). Formal ontology and Information Systems. 1st International Conference on Formal Ontologies in Information Systems, FOIS'98. Trento, Italy, IOS Press: 3-15.

Gupta, D. and N. Prakash (2001). "Engineering methods from method requirements specifications." Requir. Eng. 6(3): 135-160.

Henderson-Sellers, B. (2005). Underpinning a Method Engineering framework with a powertype-based metamodel – the FAME project http://www.pa.icar.cnr.it/cossentino/al3tf3/docs/hs.pdf, Accessed 07-2008.


180

Henderson-Sellers, B., C. Gonzalez-Perez, et al. (2008). Comparison of method chunks and method fragments for Situational Method Engineering. 19th Australian Conference on Software Engineering (aswec 2008). Perth, Australia 479-488.

Henderson-Sellers, B., C. González-Perez, et al. (2007). Situational Method Engineering: fragments or chunks? CAiSE Forum 2007. J. Eder, S. L. Tomassen, A. L. Opdahl and G. Sindre, CEUR-WS.org. 247: 89-92.

Herrera, S. I., D. Pallioto, et al. (2005). Ontological Modelling of Information Systems from Bunge's Contributions. 17th International Conference on Advanced Information Systems Engineering (CAiSE) Workshops 2005, Porto, Portugal, FEUP Edições.

Hesse, W. and A. Verrijn-Stuart (2000). Towards a theory of Information Systems: the FRISCO approach. 10th European-Japanese Conference on Information Modeling and Knowledge Bases. Saariselkä, Finland.

Honderich, T., Ed. (1995). The Oxford companion to Philosophy. New York, Oxford University Press.

ISO (1987). Information processing systems - Concepts and terminology for the conceptual schema and the information base. ISO/TR 9007:1987. J. J. v. Griethuysen (ed.), ISO TC97/SC5/WG3.

ISO/IEC (2001). Software engineering - Product quality - Part 1: Quality model. ISO/IEC 9126-1

ISO/IEC (2007). Software Engineering - Metamodel for development methodologies. ISO/IEC 24744

Jacobson, I., G. Booch, et al. (1999). The Unified Software Development Process, Addison-Wesley Professional.

Jakobson, R. (1990). The speech event and the functions of language. On language. M. Monville-Burston and L. R. Waugh (ed.). Cambridge, Harvard University Press: 69-79.

Karlsson, F. and P. J. Ågerfalk (2004). "Method configuration: adapting to situational characteristics while creating reusable assets." Information and Software Technology 46(9): 619-633.

Karlsson, F. and K. Wistrand (2006). "Combining method engineering with activity theory: theoretical grounding of the method component concept " European Journal of Information Systems 15(1): 82-90.

Keen, C. and C. Lakos (1996). An analysis of the design constructs required in process modelling. Proceedings of the 1996 International Conference on Software Engineering: Education and Practice (SE:EP '96), IEEE Computer Society.

VIII. References

181

Kent, W. (1978). Data and Reality: Basic Assumptions in Data Processing Reconsidered. New york, Elsevier.

Kruchten, P. (2003). The Rational Unified Process: An Introduction, Third Edition, Addison-Wesley Professional.

Kumar, K. and R. J. Welke (1992). Method engineering, a proposal for situation-specific methodology construction. Systems analysis and design : a research agenda. Cotterman and Senn (ed.), Wiley: 257-268.

Langefors, B. (1977). Theoretical analysis of Information Systems (4th ed). Lund, Sweden, Studentlitteratur.

Limbourg, Q. and J. Vanderdonckt (2004). Comparing task models for user interface design. The handbook of task analysis for Human-Computer Interaction. D. Diaper and N. Stanton (ed.), Lawrence Erlbaum Associates.

Lindland, O. I., G. Sindre, et al. (1994). "Understanding Quality in Conceptual Modeling." IEEE Softw. 11(2): 42-49.

Lockemann, P. C. and H. C. Mayr (1986). Information System Design: Techniques and Software Support. Information Processing 86. H.-J. Kugler (ed.). Amsterdam, The Netherlands, North-Holland.

Lyytinen, K. (1987a). "Different perspectives on information systems: problems and solutions." ACM Comput. Surv. 19(1): 5-46.

Lyytinen, K. (1987b). "Two views of information modeling." Inf. Manage. 12(1): 9-19.

Lyytinen, K. and R. J. Welke (1999). "Guest editorial: Special issue on meta-modelling and methodology engineering." Inf. Syst. J. 24(2): 67-69.

Mallea, B. F. and J. Knobeb (1997). "The folk concept of intentionality." Journal of Experimental Social Psychology 33(2): 101-121.

McGuinness, D. L. (2003). Ontologies come of age. Spinning the Semantic Web: Bringing the World Wide Web to its full potential. D. Fensel, J. i. Hendler, H. Lieberman and W. Wahlster (ed.). Cambridge, Massachussets, USA, MIT Press.

Milton, S. and E. Kazmierczak (1999). Enriching the ontological foundations of modelling in Information Systems. Ontology, Semiotics and Practice 1999 - Information Systems Foundations Workshop, Sydney, Australia, Macquarie University.

Milton, S. and E. Kazmierczak (2004). "An ontology of data modelling languages: a study using a common-sense realistic ontology." Journal of Dababase Management 15(2): 19-38.


182

Milton, S., E. Kazmierczak, et al. (2001). An ontological study of data modelling languages using Chisholm’s ontology. 11th European-Japanese Conference Information Modelling and Knowledge Bases, Maribor.

Mirbel, I. and J. Ralyté (2005). "Situational Method Engineering: combining assembly-based and roadmap-driven approaches." Requir. Eng. 11(1): 58-78.

Molina, P. J. (2003). Especificación de interfaz de usuario: de los requisitos a la generación automática. Departamento de Sistemas Informáticos y Computación. Valencia, Universidad Politécnica de Valencia: 382.

Molina, P. J., S. Meliá, et al. (2002). JUST-UI: A User Interface Specification Model. Proceedings of III Computer Aided Design of User Interfaces, CADUI'2002, Les Valenciennes, Francia., Kluwer Academics Publisher.

Moreira, A., A. Rashid, et al. (2005). Multi-Dimensional Separation of Concerns in Requirements Engineering. Proceedings of the 13th IEEE International Conference on Requirements Engineering (RE'05) - Volume 00, IEEE Computer Society: 285-296.

Morgan, T. (2002). Business rules and Information Systems - Aligning IT with business goals, Addison-Wesley.

Mylopoulos, J. (1998). "Information modeling in the time of the revolution." Inf. Syst. 23(3-4): 127-155.

Nunes, N. J. (2001). Object Modeling for User-Centered Development and User Interface Design: The Wisdom Approach. Funchal, Portugal, PhD at Universidade da Madeira: 285.

Nunes, N. J. and J. F. e. Cunha (2000). "Wisdom: a software engineering method for small software development companies." IEEE Software 17(5): 113-119.

Nunes, N. J. and J. F. e. Cunha (2001). Wisdom-Whitewater interactive system development with object models. Object modeling and user interface design: designing interactive systems, Addison-Wesley Longman Publishing Co., Inc: 197-243.

Nunes, N. J., M. Toranzo, et al. (1999). Interactive system design and object models. Workshop on Interactive System Design with Object Models (WISDOM'99). Object-Oriented Technology. ECOOP'99 Workshop Reader: ECOOP'99 Workshops, Panels, and Posters, Lisbon, Portugal, June 1999. Proceedings. A. Moreira (ed.), Springer Berlin. 1743/1999.

Olivé, A. (2005). Conceptual Schema-Centric Development: A Grand Challenge for Information Systems Research. Proceedings of the 16th Conference on Advanced Information Systems Engineering. Ó. Pastor and J. F. e. Cunha (ed.). Porto, Portugal, Lecture Notes in Computer Science vol 3520, Springer-Verlag: 1-15.

VIII. References

183

OMG (2003a). MDA guide version 1.0.1 http://www.omg.org/docs/omg/03-06-01.pdf, Accessed 03/2008.

OMG (2003b). UML 2.0 OCL Specification http://www.omg.org/docs/ptc/03-10-14.pdf, Accessed 01/2007.

OMG (2005a). MDA. Model Driven Architecture http://www.omg.org/mda/, Accessed 01/2007.

OMG (2005b). MOF QVT final adopted specification http://www.omg.org/cgi-bin/apps/doc?ptc/05-11-01.pdf, Accessed 06/2008.

OMG (2005c). Unified Modeling Language: Superstructure version 2.0 http://www.omg.org/docs/formal/05-07-04.pdf, Accessed 04/2007.

OMG (2006). Meta Object Facility (MOF) core specification v2.0 http://www.omg.org/cgi-bin/apps/doc?formal/06-01-01.pdf, Accessed 03/2008.

OMG (2007). Ontology Definition Metamodel v1.0 beta 2 http://www.omg.org/docs/ptc/07-09-09.pdf, Accessed 07/2008.

Opdahl, A. L. and B. Henderson-Sellers (1999). Evaluating and improving OO modelling languages using the BWW-Model. Ontology, Semiotics and Practice 1999 - Information Systems Foundations Workshop, Sydney, Australia, Macquarie University.

Opdahl, A. L. and B. Henderson-Sellers (2001). "Grounding the OML metamodel in ontology." Journal of Systems and Software 57(2): 119-143.

Opdahl, A. L. and B. Henderson-Sellers (2002). "Ontological evaluation of the UML using the Bunge–Wand–Weber model." Software and Systems Modelling (SoSyM) 1(1): 43-67.

Opdahl, A. L., B. Henderson-Sellers, et al. (2000). An ontological evaluation of the OML metamodel. Proceedings of the IFIP TC8/WG8.1 International Conference on Information System Concepts: An Integrated Discipline Emerging, Kluwer, B.V.

Opdahl, A. L., B. Henderson-Sellers, et al. (2001). "Ontological analysis of whole-part relationships in OO-models." Information and Software Technology 43(6): 387-399.

Opdahl, A. L. and A. Sølvberg (1992a). Conceptual integration of Information System and Performance Modelling. Proceedings of the IFIP TC8/WG8.1 Working Conference on Information System Concepts: Improving the Understanding, North-Holland Publishing Co.: 273-294.

Opdahl, A. L. and A. Sølvberg (1992b). A framework for performance engineering during Information System development. Advanced Information Systems Engineering, CAiSE 1992, Manchester, UK, Springer.


184

OpenCYC (2007). OpenCyc 1.0.2 computer software and documentation http://www.opencyc.org/, Accessed 02/2007.

Pastor, Ó. (1992). Diseño y desarrollo de un entorno de producción automática de software basado en el modelo orientado a objetos (in Spanish). Department of Information Systems and Computation. Valencia, Spain, Technical University of Valencia.

Pastor, Ó., J. Gómez, et al. (2001). "The OO-method approach for information systems modeling: from object-oriented conceptual modeling to automated programming." Information Systems 26(7): 507-534.

Pastor, Ó., F. Hayes, et al. (1992). OASIS: An Object-Oriented Specification Language. CAiSE 1992, Manchester, United Kingdom, Springer-Verlag.

Paternò, F. (2000). Model-based design and evaluation of interactive applications, Springer-Verlag, Berlin, Germany.

Paternò, F., C. Mancini, et al. (1997). ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models. Proceedings of the IFIP TC13 Interantional Conference on Human-Computer Interaction, Chapman & Hall, Ltd.: 362-369.

Pederiva, I., J. Vanderdonckt, et al. (2007). The beautification process in model-driven engineering of user interfaces. XI eleventh IFIP TC13 International Conference on Human-Computer Interaction (INTERACT 2007), Rio de Janeiro, Brasil, Springer Lecture Notes in Computer Science.

Peirce, C. S. (1998). What is a Sign? The essential Peirce. Selected philosophical writings. Vol 2. (1893-1913). Indiana, USA, Indiana University Press.

Quine, W. V. O. (1960). Word and object. Cambridge, Massachusetts, MIT Press.

Ralyté, J., S. Brinkkemper, et al., Eds. (2007). Situational Method Engineering: Fundamentals and Experiences. IFIP International Federation for Information Processing, v. 244, Springer.

Rational (2003). Rational Unified Process version 2003.06.00.65, Rational Software Corporation, Accessed

REA (2005). Diccionario panhispánico de dudas, Real Academia Española.

Rittel, H. and M. Webber (1973). "Dilemmas in a general theory of planning." Policy Sciences 4: 155-169.

Rolland, C. (2007). Capturing system intentionality with Maps. Conceptual modelling in information systems engineering. J. Krogstie, A. L. Opdahl and S. Brinkkemper (ed.), Springer.

Rosemann, M., P. Green, et al. (2004). A procedural model for ontological analyses Information Systems Foundations: Constructing and Criticising

VIII. References

185

Workshop. D. Hart and S. Gregor. The Australian National University, Canberra.

Rumbaugh, J., M. Blaha, et al. (1991). Object-Oriented Modeling and Design. Englewood Cliffs, New Jersey, USA, Prentice Hall.

Russell, B. (1908). "Mathematical logic as based on the theory of types." American Journal of Mathematics 30(3): 222-262.

Russo, N., J. Wynekoop, et al. (1995). The use and adaptation of system development methodologies. International Conference of IRMA (International Resources Management Association), Atlanta.

Schipper, M. and S. Joosten (1996). A validation procedure for information systems modelling techniques. Workshop on Evaluation of Modeling methods in Systems Analysis and Design, 8th Conference on Advanced Information Systems Engineering (CAISE’96). Heraklion, Grece.

Shannon, C. E. (1948). "A mathematical theory of communication." Bell System Technical Journal 27: 379-423 & 623-656.

Siau, K. and M. Rossi (1998). Evaluating of information modeling methods - Review. 31st Hawaii International Conference on Systems Science.

Sølvberg, A. (1980). A contribution to the definition of concepts for expressing users' information systems requirements. Entity-Relationship Approach to Systems Analysis and Design. Proc. 1st International Conference on the Entity-Relationship Approach. Los Angeles, USA, North-Holland: 381-402.

Sowa, J. F. (2000). Knowledge representation: Logical, philosophical, and computational foundations. Pacific Grove, CA, USA, Brooks/Cole Publishing Co.

Stamper, R. (1985). Management epistemology: garbage in, garbage out. Knowledge Representation for Decision Support Systems. Durham, Elsevier.

Stamper, R. (1986). A logic of social norms for the semantics of business information. Database Semantics (DS-1). T. B. Steel and R. Meersman (ed.). Amsterdam, North-Holland: 233-253.

Valverde, R. and M. Toleman (2007). Ontological evaluation of business models: comparing traditional and component-based paradigms in information systems re-engineering. Ontologies: a handbook of principles, concepts and applications in Information Systems, Springer.

Wand, Y., D. Monarchi, et al. (1995). "Theoretical foundations for conceptual modeling in information systems development." Decision Support Systems 15.


186

Wand, Y. and R. Weber (1990). "An ontological model of an Information System." IEEE Transactions on Software Engineering 16(11): 1282 -1292.

Wand, Y. and R. Weber (1993). "On the ontological expressiveness of Information Systems analysis and design grammars." Information Systems 3: 217-237.

Wand, Y. and R. Weber (1995). "On the deep structure of information systems." Inf. Syst. J. 5: 203-223.

Weber, R. (1997). Ontological foundations of Information Systems. Queensland, Australia, Coopers & Lybrand.

Weber, R. (1999). The Information Systems discipline: The need for and nature of a foundational core. IS Foundations Workshop; Ontology, Semiotics and Practice, Macquarie University.

Wertheimer, M. (1938). Gestalt theory. A source book of Gestalt psychology. W. D. Ellis (ed.). London, Gestalt Journal Press (reprint edition 1997, originally published in German): 1-16.

Wieringa, R. (1998). "A survey of structured and object-oriented software specification methods and techniques." ACM Comput. Surv. 30(4): 459-527.

Winograd, T. and F. Flores (1987). Understanding Computers and Cognition: A New Foundation for Design. Boston, Addison-Wesley.

Winston, M. E., R. Chaffin, et al. (1987). "A taxonomy of part-whole relations." Cognitive Science 1: 417-444.

Wohed, P. and B. Andersson (2005). Meta-Modelling as a Means for Improved Communication and Interoperability - The Case of Frisco. Enterprise Modelling and Ontologies for Interoperability (EMOI-INTEROP'05), co-located with CAiSE'05. Porto, Portugal.

Yourdon, E. (1989). Modern structured analysis. Upper Saddle River, New Jersey, USA, Yourdon Press Computing Series.

españa (master thesis 2008) a generic model of information systems

Documents