Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
On the Transition from Computation Independent to Platform Independent Models Milan Karow European Research Center for Information Systems (ERCIS) Department of Information Management, University of Muenster Leonardo-Campus 3, D-48149 Muenster
[email protected]
Andreas Gehlert Technische Universitaet Dresden Department of Business Management and Economics Chair of Business Informatics, esp. Systems Engineering D-01062 Dresden
[email protected]
ABSTRACT
The Model Driven Architecture (MDA) describes software development based on models on different levels of abstraction. The development process is outlined as a sequence of model transformations which add specific details to the software models with each subsequent step. The OMG MDA guide refers to the computation independent model (CIM) as the highest level of abstraction. However this model type is disregarded by most MDA methodologies and tools, which start their transformation process on the level of platform independent software models (PIM). This paper investigates the role and nature of the CIM, especially focussing on development processes for management information systems. Therefore, existing transformational approaches for the transition from models as real world perceptions to software designs are evaluated. Finally the transformational view on software development is extended by decision theory aspects during the design task, which significantly influence the feasibility of design process automation. Keywords
Model Driven Architecture, model transformation, conceptual modeling, analysis, design, Computation Independent Model, Platform Independent Model INTRODUCTION
In the field of software engineering, modelling has become a major technique to deal with increasing complexity and risk of software development projects in the last decades. Models are used to analyse, design and document software artefacts in different stages of the software life cycle. They as well represent an important instrument of communication between the different stakeholders within a development process (Génova, Valiente and Nubiola 2005). The MDA approach has been established as a standard framework for model driven software development. Various methods and supporting CASE tools are existent and in use for large scale projects. The realisation of MDA however, is heterogeneously addressed by software engineers and tool manufacturers. While there are numerous approaches for model transformation between platform independent to platform specific models, the artefact of the computation independent model has been rather ignored by recent developments. In fact none of the MDA committed companies listed by the OMG provides a dedicated transformation methodology for computation independent models, very few consider at least their construction. Given the rising importance of business process management and modelling, it seems obvious that a transition between computation independent models and platform independent software models can be considered as being critical for the development of high-quality business software which meets the business and user requirements. Furthermore, introducing such systems into a working corporate environment implies severe impacts on the structural and procedural design of business organisations in order to significantly leverage productivity and efficiency (Hammer and Champy 1994). The main question investigated in this paper is how the information of such business models influences the design of application system. This raises the question which information is expected to be modelled in computation independent models and whether this information can be processed in a formal fashion to generate an application system design. The second Chapter will discuss the software development process and the different types of models that support various tasks.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
Chapter 3 shows existing approaches that intend to transform real-world models into software designs and points out their conditions and limits. The final chapter investigates the software design task and extends the transformational view on the development process with decision theory aspects. MODEL DRIVEN SOFTWARE DEVELOPMENT
As mentioned above, not only does the business environment determine the form and functions of the application system to be developed, but also has the introduction of such systems significant influence on organisational structure and processes. This suggests utilising modelling techniques for the whole information system including its non-automated tasks and their respective owners, leading to several model types that clearly differ regarding their properties. Model Types in Information Systems Engineering
A common distinction of model types in software engineering is to categorize them depending on their position in the software life cycle. This leads to stereotypes like analysis models, design models and - regarding code as a textual form of model - implementation models. Especially for the term analysis model this classification is imprecise, for different kinds of models fall into that phase of system development and not all of them have analytic character. Genova et al. distinguish two types of analysis models depending on their semiotic reference (Génova et al. 2005). The first type of models refers to a perception of the real world. The intention of these models is a better understanding of the environment in which an application system will be integrated. The modelled part of the world is also referred to as the Universe of Discourse. The second type of analysis models represents the requirements to be met by the system. These models already refer to the software system and are therefore rather synthetic than analytic. But in contrast to design models, which refer to the software system as well, requirements models represent a different kind of abstraction by modelling the external view. In terms of the MDA Genova et al. refer to the real world model as CIM, the requirements model as PIM and the design model as platform specific model (PSM). The most obvious problem with this mapping is that PIM and PSM are no absolute terms but rather roles a particular model can take in the model driven development process. The decision whether a model is to be regarded as one or the other is determined by the chosen definition of the platform term. A platform can exist on different levels of abstraction, e. g. programming paradigms, languages or specific application server technologies. Transformation being the main concept of MDA, the terms PIM and PSM merely mark a model as the transformation's input or output. Additionally, considering the fact that the development process can include several serial transformation steps, this implies that a model resulting as PSM from a previous step can represent the PIM in a subsequent transformation. A second difficulty is that the intention of having platform independent models is to preserve investments made into the development of particular software solutions. These solutions, which are documented independently from a certain implementation technology, are intended to be reused when migrating the software to a new technology - without having to redevelop the entire product (OMG 2003). Requirements models however do not represent an actual solution but rather are expected to document and structure the given problem. Regarding requirements models as means of a PIM, i. e. use them as input to an MDA transformation, will make these models fail their purpose of being a problem statement (Kaindl 1999). Given the fact that computation independent models semantically refer to real world systems, requirements models do not have a proper counterpart in the MDA terminology. They relate exclusively to the software system (Génova et al. 2005), although they may use the terminology of the respective material domain. Considering the importance of business reengineering in order to realise the potential of introducing an information system it is possible to distinguish between two types of models which model the Universe of Discourse and therefore could be categorized as CIMs - the actual state organisational model and the target state organisational model. These two model types again share a problem-solution-relationship concerning the corporate and process structure. The target state organisational model can not fully be declared as being computational independent, for it assumes the existence of the application system to be developed as an organisational entity and task owner. Thus, it is the most valuable source to derive functional requirements by interpreting this model concerning the functions and tasks owned by the application system. However, non-functional requirements (NFA) must be elicited directly from the stakeholders of the development process and although interrelated with the functional requirements can be regarded as being a distinct model type. This view is encouraged by the fact that NFA are stated in natural language rather than semi-formal techniques that dominate functional requirements descriptions. Non-functional requirements comprise several different demands (e.g. regarding process, cost, time requirements etc.) – in this paper we will focus on quality requirements. Figure 1 illustrates the different model types and depicts their connection via transformational or constructive tasks.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
Figure 1. Model Types in Business Systems Engineering
Modeling Languages
The introduced model types strongly differ in the languages utilised for their construction. Modeling languages can be classified into three types (Fraser, Kumar and Vaishnavi 1994): •
formal languages: Formal modeling languages have a strictly defined syntax. The restricted set of signs and rules to combine these signs is defined in the meta model of the respective language. Formal languages have no material semantic whatsoever, i. e. their symbols do not relate to real world concepts. The formal semantics of a language describe precise rules on how to transform sign chains between different formal systems, relying on mathematical principles. Examples are programming languages.
•
natural languages: Natural languages do neither have a defined syntax nor semantic. These languages evolved naturally in their specific community. Syntax and semantics of natural languages are determined by a common consensus and contain multitude redundancies and inaccuracies. The special language of a business domain (e. g. a particular organisation or a specific industry) also is regarded as being natural.
•
semi-formal languages: Semi-formal languages have a formal component which precisely describes the set and combination rules of graphical elements (syntax) but also a material component (semantics). The semantics of semiformal models are composed of the concepts which the language elements refer to and the natural language used to name instances of these elements. Thus semi-formal models can only be interpreted by model users that are capable to comprehend the special (natural) language of the business domain.
Business models are typically constructed by utilising a semi-formal language such as ARIS-EPC, ER models and the like. Requirements models use similar techniques for the description of functional requirements, non-functional requirements are--when explicitly documented - modelled by textual descriptions using natural language. MODEL TRANSFORMATION APPROACHES
This section will exemplarily investigate some existing approaches for the transformation of real world perceptions into software design models. Therefore an evaluation framework is outlined, which guides the survey on the several model transformation technologies. The properties taken into consideration are derived from basic quality requirements for the models of both the analysis and the design phase.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
Transformation Evaluation Framework
A prominent quality for an analysis model being a problem statement is its completeness. This is especially obvious for the goal of automated transitions from analysis to design, for a formal set of rules must consider every single significant information. Models that refer to systems in reality however can not be proven to be complete - real world phenomena are always perceived by individuals and therefore these perceptions can not be considered as being objectively correct or false. Models of a material domain can only be evaluated and agreed on being sufficient rather than complete by the stakeholders of the modelling process (modellers, domain experts, system designers etc.). This consensus is dependent on the purpose of the respective model as well as a given time of validity. A modelling and transformation methodology ought to support the process of consensus finding. That also includes the utilisation of modelling languages comprehensible for all stakeholders during the respective development phase. Furthermore, all models and modelling languages must strictly distinguish between material and software concepts to fulfil their respective purpose as either being a real world representation or a description of software system properties (Kaindl 1999). This criterion will be referred to as semiotic integrity. Quality requirements for design models are strongly interrelated with general software quality requirements, for many of those are already determined in early design phases such as the construction of the system architecture (Bass, Clements and Kazman 2003). A central argument for evaluating software designs is their handling of non-functional requirements elicited in the analysis phase. These requirements especially determine the structure of a software system whereas functional requirements emphasise expected behaviour. Functional requirements can be fulfilled by almost any system structure, even one monolithic function. Architectural and structural issues are not significant to system design until non-functional requirements such as performance, reliability or maintainability are to be met. The maintainability of models generated by the transformation is an important criterion when these models are intended to be changed manually in the consecutive development process. In addition to requirements derived from source and target models, there are some criteria that arise from development process requirements. They add up to a measurement which will be referred to as transformation applicability. Influencing factors are the possibility of transformation control (parameters etc.), the flexibility of the transformation (limitation on particular system types), the traceability of generated artefacts, roundtrip engineering (protection of manual changes) and the range of the transformation. These criteria have been applied to several transformation technologies, most of which have been introduced in the first half of the last decade. The reason for the evaluation of these particular and rather “out-of-date” techniques is their emphasis on model transformation from analysis to design, which has been abandoned by most of today’s process models. Currently applied methodologies (such as the Unified Process) tend to accentuate the creative nature of the design process as a complex and experience-driven task (Jacobson, Booch and Rumbaugh 1999). With MDA on the rise however, the transformational view on software development regains significance and therefore is a rewarding object of research. The Ontological State Machine
The approach of the ontological state machine for information system development has been first introduced by Wand and Weber (Wand 1989, Wand and Weber 1989). According to their theory, information systems can be regarded as being direct representations of respective real world systems. The approach utilises the phase model covering the phases analysis, design and implementation. The purpose of the analysis phase is to build a formal model of the real system as perceived. The analysis model is expected to be a faithful representation of the real world modelled. The description of the real world is realised complying with the ontology of Bunge, which defines systems as a triple of state space, system law and the set of events. A system has a certain state, which can be stable or unstable. In case of an unstable state, the system law determines the response to transfer the system to a stable state of its lawful state space. Unstable system states are triggered by external events of the systems environment. In the design phase of information system development, the state model of the real system is transformed homomorphically to a system design. The part of reality modelled in the analysis phase represents the environment for the information system. Information system and its respective environment are coupled by events, i. e. that external events for the real system must trigger a system response that generates corresponding events for the information system. Thus the information system's state is always in match with the state of the real world system. For implementation purposes, the ontological elements are simply mapped to technological counterparts---events and states represent data, system laws are expressed as processes.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
The approach however does not take into consideration any non-functional requirements. Technological or economical restrictions of software development as well as user aspects are ignored. The information systems structure and architecture is not discussed as a matter of security, availability or performance---the system's decomposition is solely determined by the good decomposition model (Wand and Weber 1995), which states the formal requirement of independence to be met by respective subsystems. The model type creates in the analysis phase of the approach can be classified as the target organisational model for it describes reality at information system's runtime. The model type referred to as the system design however has more in common with a functional requirements specification, for it dominantly describes system behaviour from an outside perspective and does not address the technological solution considering implementational restrictions at all, which can be regarded as being the most important function of the design phase. Another significant concern is the question, if a business environment can be fully described in a formal model focusing on state and behaviour and if a reconstruction of reality is a considerable approach for an information system to support significant information related processes of the organisation rather than simulating the system. Similar problems appear with the object oriented approaches discussed in the next section. Object Oriented Transformation Approaches
Object oriented modelling techniques emerged from advances in the field of programming languages. The object oriented paradigm evolved from several influences in computer science, such as simulation, operating systems, data abstraction and artificial intelligence. The object concept has been implemented first by languages like SIMULA and later Smalltalk-80 which was able to boost the popularity of object oriented programming (OOP) (Capretz 2003). The notion of the term object in OOP was however not related to real world entities but rather represented formal and abstract concepts of respective programming languages. With the introduction of object oriented analysis techniques, a relation between modelled objects and entities of reality has been adopted. The main advantage propagated by many authors was the utilisation of one singular concept throughout the whole development process and thereby seamlessly integrating its different phases (Kaindl 1999). OOA and OMT
Popular techniques were the Object-oriented Analysis (OOA) of Coad and Yourdon (Coad and Yourdon 1991a, Coad and Yourdon 1991b), as well as the Object Modelling Technique (OMT) of Rumbaugh et al. (Rumbaugh, Blaha, Premerlani, Eddy and Lorensen 1991) which adopted the object oriented paradigm for conceptual modelling for the analysis phase. Both approaches focus on a structural view, using class and object diagrams to visualise association, aggregation and generalization relationships between objects and classes. The transformation approach of both methodologies directly carries the resulting models of the analysis phase into the design. OOA models are mapped into the Problem Domain Component, which represents a particular partition of the Object-oriented Design (OOD). The remaining three partitions deal with issues like data persistence and retrieval, user interface and task management. Note that although these additional partitions are critical for the attainment of non-functional requirements, they are not influenced by analysis results. The OMT does not explicitly distinguish between analysis and design models. The object models created during the analysis represent the starting point of the design phase, during which these models are extended by implementational details. OMT design has two phases: system design and object design. During the first part, the application system is outlined architecturally; the second phase covers the detailed design. Analysis results only reappear in the detailed design and therefore do not influence the architecture. It is obvious that both methodologies lack a consistent understanding of the object term - there is no distinction between material real world and formal software concepts. The finding of a consensus between software and domain experts is obstructed by the utilisation of IT-specific concepts during conceptual modelling. This threatens the semantic consistence of the analysis models and leads to precipitated design influences on the modelling task (Kaindl 1999, Parsons and Wand 1997). Non-functional requirements are neither modelled in analysis nor take a defined influence on the design task. The compliance of the application system with respective user requirements is therefore strongly dependent on the designer's experience.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
Recursive Design
The Recursive Design (RD) of Shlaer and Mellor (Shlaer and Mellor 1992, Shlaer and Mellor 1997) is based on yet another object oriented modelling methodology (also called OOA) which resembles the techniques discussed above in many ways. A noticeable difference is the fact, that RD can be applied to the development of applications which eventually are not implemented in an object-oriented programming language. The central concept of the approach is the domain, which represents a real or abstract universe of discourse inhabited by object with a specific behaviour. These domains can be analysed and modelled using the OOA methodology. Not only is the application domain, which is an abstraction of a part of the real world, modelled that way but also the systems architecture. The architecture defines rules and mechanisms that are applied to all elements of the software system. The term architecture however is used differently in RD - it does not describe the general structure of complex system components but rather a framework of design elements thoroughly designed down to their particular behaviour. This system of software elements can be constructed independently from a particular application by analysing the general characterization of the system and then designing the architecture. However, with its archetypes (code templates) related to the modelled concepts, the architectural model rather represents a design language (and therefore a meta model) than a particular design. The actual design is derived by type-mapping the application domain model to architectural concepts, so building the actual design instance (cf. Figure 2).
meta model layer
object model layer
OOA model of the application domain
OOA meta model type mapping OOA model of the architectural domain
population application design (architectural instance)
type mapping target programming language
transformation (instance) instantiation relation transformation source/target language
generation generated application code
transformation (definition) model - method artifact model
Figure 2. Method Artifact Relations in Recursive Design
Like formerly described object oriented methods, Recursive Design most obviously lacks a consistent object definition. The focus on behaviour throughout the method however rather resembles it with the ontological state machine, yet RD includes tasks for the realisation of the system in software. The limitation on dynamics however restricts its use to real-time applications, where RD has been applied successfully (Kozlowski, Carey, Maguire, Whitehouse, Witzig and Sorensen 1995), but makes it less useful for business applications with their function oriented environment. In contrast to the methods formerly discussed, non-functional requirements are explicitly taken into consideration when constructing the architectural model - but since this (meta) model is an artefact to reuse, project-specific requirements can not be followed.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
Survey Results
Wand/Weber
OOA/D
OMT
RD
consensus support
n/a
weak
weak
weak
semiotic integrity
concept separation explicitly negated
weak separation , only by model types not by object definition
no concept separation
explicit domain separation, but no clear object definition
NFA handling
explicitly ignored
not considered
not considered
elicitation only in generic architectural design, not application specific
no applicable design resulting
no explicit limitation, rather sufficient for real-time systems; no protection of manual changes
like OOA, but analysis model can no longer be separated during design
broader applicability by support of non-OO languages, also rather sufficient for real-time apps.
applicability
Table 1. Survey Results
All methodologies investigated have been showed to be not suitable for the transformation of organisational business models into software design. The major difficulty of all methodologies is the utilisation of concepts originally created to represent software components to model parts of reality. This way, implementational decisions take a precipitated influence on the way the application domain is modelled. The contribution made by experts of the material domain is additionally impaired by the use of a language not mastered by this particular group of stakeholders. The high influence of non-functional requirements on design decisions beginning from the early architectural outline of an application system is virtually ignored by all approaches - few (such as RD) at least arrange for the elicitation of such requirements. THE DESIGN TASK BEYOND TRANSFORMATION
This section is intended to broaden the view on software design by not regarding the design task as a mere transformation of analysis models into software solutions. Transformation tasks can be described as black box systems that create an output depending on a respective transformation input. The input of a transformation has to be complete and all information must be significant for the transformation. As mentioned in the first section, the completeness of a model representing parts of the real world is not subjectindependently ascertainable - a homomorphism or isomorphism as required by the ontological approach can only be definitely proven for models of artificial, formal domains that have a defined set of distinguishable entities and behaviour. Thus, it is also impossible to guarantee all information modelled to be correct or significant for the system’s development. Decision Aspects
In software development projects, a system’s designer has to choose from a virtually infinite set of software solutions to meet the requirements specified. As discussed, functional requirements can be met by numerous designs. In real life projects there will be a restricted set of possibilities to choose from, depending on the designer’s experience or available reusable artefacts. To elect a particular solution, a decision is made considering non-functional requirements. Different from the functional requirements that can and have to be met to their total, non-functional requirements can mostly only be achieved up to a certain degree. Additionally different requirements often are competitive (Mylopoulos, Chung and Yu 1999), so that a designer has to balance the influence of a particular design on their fulfilment according to certain priorities. Regarding this, it is obvious, that software design is not a mere transformation but rather a decision task. The question arising from this fact is, whether these decisions can be formalized and automated or remain a strictly manual task. To formalize the decision process, the variables influencing the decision have to be fully operational. Furthermore it is necessary to fully
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
describe the dependencies between the solution alternatives and their impact on the achievement of decision goals (requirements) in a functional way. Software decision problems however suffer from certain lacks in structuring. The use of natural and semi-formal language implies potential ambiguities in the problem statement. The influence of design alternatives on goal achievement is not fully computable – the decision is made under uncertainty. Additionally, software requirements are a subject to change and might potentially be incomplete when beginning the design phase. The problem definition can be specified more precisely by iterating the decision process. In fact, most process models in software engineering provide the possibility to iterate through development phases. Each iteration results in a better structuring of the problem by giving more information to the decision makers. CONCLUSION
The MDA has given rise to the question how far the abstraction from technical details can go. By providing for a means of organisational modelling with the computational independent model, it is evident to discuss its transformation to a platform independent model so raising the level of abstraction to a business level. This paper has shown that the notion of the different model types in MDA is not quite definite and lacks a clear definition. Additionally, it has been revealed that there is no model type in MDA covering the requirements for the software system in development, which is the actual source model on the transition from analysis to design. By evaluation transformation oriented approaches on model driven software development, we were able to show the defects associated with the transformational view on the transition. All of the transformation approaches investigated intended to map a model which is a perception of the real world (in MDA terms: a CIM) to a software design model (PIM or PSM). By resembling the structure of real world perceptions without regarding software quality requirements, the transformation results are potentially insufficient and unusable in the design process. It has been showed, that software design is a poorly structured decision task which depends on manual decisions and iterations. The computation independent model however merely informs the decision makers about the system’s context but does not influence design decisions in a functional describable way. REFERENCES
1. Bass, L., Clements, P. and Kazman, R. (2003) Software architecture in practice, 2. ed. Edition SEI series in software engineering, Addison-Wesley, Boston. 2. Capretz, L. F. (2003) A brief history of the object-oriented approach, SIGSOFT Softw. Eng. Notes, 28, 2, 6. 3. Coad, P. and Yourdon, E. (1991a) Object-Oriented Analysis, 2. ed., 4. pr. Edition, Prentice Hall, Englewood Cliffs, NJ. 4. Coad, P. and Yourdon, E. (1991b) Object-Oriented Design Yourdon Press computing series, Yourdon Press / Prentice Hall, Englewood Cliffs, NJ. 5. Fraser, M. D., Kumar, K. and Vaishnavi, V. K. (1994) Strategies for Incorporating Formal Specifications in Software Development, Commun. ACM, 37, 10, 74-86. 6. Génova, G., Valiente, M. C. and Nubiola, J. (2005) A Semiotic Approach to UML Models Proceedings of the 1st Workshop on Philosophical Foundations of Information Systems Engineering (PHISE'05). 7. Hammer, M. and Champy, J. (1994) Business Reengineering, 2. Aufl. Edition, Campus-Verlag, Frankfurt/Main [u.a.]. 8. Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The Unified Software Development Process The Addison-Wesley object technology series, Addison-Wesley, Reading, Mass. 9. Kaindl, H. (1999) Difficulties in the Transition from OO Analysis to Design, IEEE Software, 16, 5, 94-102. 10. Kozlowski, T., Carey, T. A., Maguire, C. F., Whitehouse, D., Witzig, C. and Sorensen, S. (1995) Shlaer-Mellor objectoriented analysis and recursive design, an effective modern software development method for development of computing systems for a large physics detector Proceedings of the Proceedings of the International Conference on Computing in High Energy Physics. 11. Mylopoulos, J., Chung, L. and Yu, E. (1999) From object-oriented to goal-oriented requirements analysis, Commun. ACM, 42, 1, 31--37. 12. OMG (2003) MDA Guide Version 1.0.1. 13. Parsons, J. and Wand, Y. (1997) Using objects for systems analysis, Communications of the ACM, 40, 12, 104--110. 14. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. (1991) Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ. 15. Shlaer, S. and Mellor, S. J. (1992) Object lifecycles: modeling the world in states, 7. print Edition Yourdon Press computing series, Yourdon Press, Englewood Cliffs, NJ.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
Milan Karow & Andreas Gehlert
On the Transition from CIM to PIM
16. Shlaer, S. and Mellor, S. J. (1997) Recursive Design of an Application-Independent Architecture, IEEE Software, 14, 1, 61-72. 17. Wand, Y. (1989) An Ontological Foundation for Information Systems Design Theory, in Barbara Pernici and Alex Verrijn-Stuart (Eds.) Proceedings of the Proceedings of the IFIP WG 8.4 Working Conference on Office Information Systems: The Design Process, 201 -- 221. 18. Wand, Y. and Weber, R. (1989) An Ontological Evaluation of Systems Analysis and Design Methods, in Eckhard D. Falkenberg and Paul Lindgreen (Eds.) Proceedings of the Proceedings of the IFIP TC 8 / WG 8.1 Working Conference on Information System Concepts: An in-depth Analysis, 79 -- 107. 19. Wand, Y. and Weber, R. (1995) On the deep structure of information systems, Information Systems Journal, 5, 203--223.
Proceedings of the Twelfth Americas Conference on Information Systems, Acapulco, Mexico August 04th-06th 2006
