Development- Independent Conceptual Models

Oscar Dieste Departamento de Electrónica y Sistemas – Escuela Politécnica Superior Universidad Alfonso X 28691- Villanueva de la Cañada. Madrid (Spain) e-mail: [email protected]

Abstract · Detect missing information, and errors or misinterpretations, before going ahead with The conceptual models obtained during analysis have construction [5]. two main shortcomings, which have been pointed out by Conceptual modelling is gaining in importance as several researchers: first, they are clearly oriented to a software become more complex and the problem specific development paradigm (structured, object domain moves further away from familiar to oriented, etc.); second, once the conceptual models have developers. The reason is that modelling acts as the been obtained, it is really difficult to change to another starting point for and, thus, being able to development paradigm, because of the model orientation solve customer and/or user problems. This is clear from to a specific development approach. the work of several researchers, who claim that proper Nevertheless, analysis task requires that models be conceptual modelling is crucial for the future independent of any ‘vision of the world’, as those development of software. McGregor [6], Bonffati [7] or suggested by current development . Model Høydalsvik [8], for example, stress how important independence makes problem comprehension easier. conceptual modelling is for ensuring that CMs faithfully This is why the conceptual models used nowadays are represent the problem to be solved in the user domain. not of use for achieving correct analysis. Nevertheless, several authors have argued that the This paper shows an alternative approach to conceptual CMs used nowadays are oriented to specific software modelling. This approach focuses on the construction of development approaches. This orientation has two special conceptual models, called Generic Conceptual repercussions: (1) CMs have computational constraints, Models, which contain no computational bounds of any that is, CM developers represent specific implementation kind. This approach can be easily integrated into the characteristics in the models [7, 8, 9]; (2) CMs prescribe usual development process, avoiding the problems now the subsequent development process, in which the CMs arising with regard to analysis. are more or less directly transformed into models [10, 11, 12, 13, 14], and their transformation to a design model related to another development paradigm is really 1. Introduction complicated and sometimes impossible. This that the CMs used nowadays are not of The requirements engineering (RE) activity is composed use for analysis. In this paper, we illustrate an alternative by four iterative tasks: elicitation, analysis, approach that aims to remove the above constraints. The documentation and validation[1]. Analysis is a critical paper is structured as follows: section 2 focuses on CMs task among them, because of the huge importance of its and their role in software development; section 3 objectives: (1) understand the problem to be solved; (2) discusses the problems with using CMs identified by develop conceptual models (CMs), which represent this several researchers, as well as the limitations we have problem understanding; and (3) define the features of an detected; section 4 introduces the hypothesis used to implementation-independent solution to the problem in define our approach; and section 5 describe the approach question, that is, identify the requirements to be satisfied we have defined for a conceptual modelling process by the future software system. CMs play a central role in independent of any development paradigm. Finally, the analysis, as they make it possible to: preliminary results of applying our approach are · Make real-world and relationships tangible discussed in section 6, as the future work to be carried [2]. out to fully validate and improve it. · Record parts of that are important for performing the task in question and downgrade 2. The Role of Conceptual Models other elements that are insignificant [3]. · Support communication among the various The term CM originally emerged in the database field. “stakeholders” (customers, users, developers, CMs were used to represent the data and relations, which testers, etc.) [4]. were to be managed by an information system, irrespective of any implementation feature [19]. The domain. This orientation to the solution is necessitated scope of the term CM has gradually broadened since the by the fact that the representations of the different CMs approval of the ISO conceptual modelling standard [20], include computer-related issues. Several researchers, where its goal was to represent the domain of discourse. mainly from the object-oriented community, have The domain of discourse is the set of data involved in the pointed out that conceptualisation methods suffer from problem to be solved and the operations that affect the this limitation: above data. In this context, only the operations that · It is argued that object-oriented methods are a represented domain rules or, in other words, specific ‘natural’ representation of the world. Nevertheless, integrity constraints of the problem to be solved were this idea is a dangerous over-simplification [9]. represented in the CM. · Object-oriented analysis has several shortcomings, Nevertheless, CMs are used for more than is most importantly in being target-oriented rather than acknowledged by the above definition. The following problem oriented [8]. citations show that CMs are used in SE to: · Object-oriented analysis techniques are strongly · Encourage the analyst to think and document in affected by implementative issues [7]. terms of the problem, as opposed to the solution There are authors that extend the criticisms to other [11]. models, too. For example, Jackson argues that: · Describe the universe of discourse in the · DFD’s are vague pictures suggesting what someone language and in the way of thinking of the thinks might be the shape of a system to solve a domain experts and users [15]. problem, but they do not say what the problem is · Formally define aspects of the physical and social [18]. world around us for the purposes of · There exists no of how a model relates to the understanding and communication [16]. real world [19]. · Help requirements engineers understand the Thus, for example, data flow diagrams are clearly domain [17]. guided by functions, key components of structured Taking into account the above definitions, it can be software and, likewise, the models used in object- said that the main characteristics of any CM are oriented analysis lead directly towards software description and understanding; that is, CMs can be used developed by means of classes, objects, messages, by developers to: polymorphism, etc., basic concepts of object-oriented · Understand the needs raised by users. software. · Reach agreement with users on the scope of the If computational characteristics are included in CMs, system and how it is to be built. these are linked to a particular implementation approach, · Use the information represented in the model as a that is, once a given conceptualisation method has been basis for building a traditional or intelligent selected to describe the problem domain, it is practically software system to meet this need. impossible to change the above method “a posteriori” without having to reanalyse the problem. This has also 3. About the Computational Orientation of been stressed by several researchers: Conceptual Models · Because of poorly understood overlap among different requirements languages, it is difficult to Several authors have pointed out that current CMs change languages mid-project [20]. sometimes fail to do their jobs of description and · The use of a CM during analysis defines nearly understanding during analysis. Criticisms can be divided univocally how the design shall be done [10]. into two major groups: · Perhaps the most difficult aspect of problem · The orientation of the conceptualisation methods, analysis is avoiding software design [11]. stressing the fact that most CMs are oriented to · It is sometimes mistakenly believed that the getting a computational solution to the problem or structures produced during analysis will and should need raised and not to easing the understanding of be carried through in design [12]. the user need. · The boundaries between analysis and design · The association between CMs and specific activities in the object-oriented model are fuzzy approaches to software development. [13]. Here, the use of a given CM during the early phases · The software system development approach is of the development process limits the number of possible preconditioned by the CM used [14]. implementation alternatives and means that only the Owing to this limitation, for example, if data flow options that are compatible with the CM used originally diagrams have been used to model the problem domain, are feasible. it will almost certainly be necessary to use the structured Many of the CMs are oriented to providing a method in later development phases; a method of object- computational solution to the problem raised in the user oriented development will have to be used following an object-oriented analysis. Therefore, if we intended to and (2) go from an understanding of the problem to a switch development paradigms, that is, for example, pass solution characterization, which moves from a very from a data flow diagram to an object-oriented design, abstract level in the early analysis (some restrictions, this transformation would lead to an information gap that characteristics, etc. of the future software system), to a is very difficult to fill. This occurs because each CM acts more concrete formulation as the developer’s knowledge like a pair of glasses used by the developer to observe the about the problem increases (a list of the desired features domain and user reality. These glasses highlight certain of the software system). features, tone down others and hide others. Once the real However, the use of CMs as a mechanism of world has been filtered through the CM, it is difficult to representation obliges a convergence of the problem retrieve anything that has been lost or condensed, even if understanding and solution synthesis processes. As the later development process requires this information. discussed earlier, CMs have computational constraints. The only way of recovering the features lost in the CM This means that as soon as the knowledge acquired by filter is to reanalyse reality using a different pair of developer is set out in a model, this automatically glasses; that is, to repeat the operation using another CM. determines some kind of ‘solution’ to the problem under This situation has already been discussed by authors like study, that is, part of the structure and/or functionality of Coleman [21], Champeaux [22] or Wieringa [23], who a software system. The high level design of the software address the incompatibility between the CMs used in the system is completely defined once the CM is complete. structured approach and object-oriented CMs, owing to The above discussion can be illustrated using a simple the conceptual difference between the elements used in example, shown in Figure 1. the two approaches. Additionally, these switches from a CM of one Conceptual Design approach to a design of another paradigm, even if they Model were possible, are not usually feasible in practice in view of the time and cost constraints and size of projects nowadays. Mostly, the CMs used are those with which Customer developers are familiar, called for by individual Manage standards or even, as specified by Mylopoulos [24], the orders models that are “in fashion”. So, in the era when the structured approach was in vogue, techniques such as Receive DFDs were used for conceptual modelling, whereas, order Receive Create today, with the rise of object-oriented programming and orders invoice design, techniques like object diagrams, interaction diagrams, etc., are employed. Orders In short, the software system development approach Accept Write Read from Orders can be said to be preconditioned from the very start, as order to Orders soon as the CMs are built. The problem with including Create computational considerations within the CM is that invoice developers are forced to make a solution-oriented decision during the early development phases, when the Figure 1. Example of design derivation problem to be solved is still not well enough understood. This means making design decisions when not all the The above example, typical of the structured information relevant to the problem is known. approach, could be stated as follows: “ACME customers Developers thus run the risk of making the wrong place orders [...]. An invoice is generated for each order, decision, because they are not in possession of all the which is sent to the customer [...]”. Without going into as information. Excepting trivial problems, this much detail as required by the method of analysis, a precondition implies that the development approach is developer using the structured approach would clearly chosen before the user need has been understood, which assign ‘Order’ and ‘Invoice’ to data stores, which means is the job of conceptual modelling. that two processes have to be considered for entering and extracting information from the above stores: ‘Receive 4. Requirements for a Development-Paradigm order’ and ‘Create invoice’. Customer, on the other hand, Independent Conceptual Model is clearly assigned to an external entity. Once these decisions have been made, the There should be two points of inflection during analysis, subsequent development process is inalterable on three each determined by its goals, that is: (1) move from an points: (1) structured design will have to be used, as it ignorance to an understanding of the problem to be would be very expensive to use any other sort of design; solved, which should be reflected in the creation of CMs, (2) each DFD builder is mapped to a given Structure Diagram builder, that is, data flows to data interchanged acquired knowledge, has been developed. This GCM is in the module interfaces and processes to modules. Data the input for the second activity, called Software System- stores and external entities are removed from the Oriented Analysis, whose the goal is to identify which structure diagram, although they are present, as they are CM is best suited for representing the problem, as well as the sources/targets of the data read/written by the to transform the GCM to the above mentioned CM. predefined modules; (3) the of the system adopts the hierarchical structure, called for by structured design. Problem Superficial Analysis Owing to the above, analysis has to be subdivided so as to prevent problem-related issues from interfering Problem-Oriented Preliminary Model with problem-solving related issues. This means that, on Analysis the one hand, CMs have to be brought closer to users, In-Depth Analysis using a language that they can understand. On the other, they need to include all the information required about Generic Conceptual Model the problem for developers to later address the software Identification of system that is to solve the problem. Indeed, it is System Type necessary to define conceptualisation methods that meet Software System- Oriented Analysis the following formal criteria of adjustment: System Type Derivation of the · Understanding the need raised by the user before Classical Conceptual considering an approach for developing a software Classical Conceptual Model Model system that meets this need. (a) (b) · The understanding of the need must be independent of the chosen problem-solving approach, that is, it Figure 2. Proposed Process must not precondition the use of any development approach. This first decomposition is too general to guide a · Having criteria for deciding which is the best developer as to how to perform analysis. Therefore, both development approach once the user need has been activities are divided into two sub-activities, as shown in understood. Figure 2(b). These criteria can only be met by redefining the Problem-Oriented Analysis is decomposed into the conceptual modelling process as now carried out in the following sub-activities: analysis task in RE. · Superficial Analysis: the problem is examined superficially in this sub-activity with the aim of 5. Proposed Approach defining a preliminary model. The goals of this sub- activity are to: (1) identify the most important The proposed approach is based on the above-mentioned elements (we use ‘element’ instead of ‘’ as criteria and is characterised by: (1) defining a detailed will be described later in the Generic Conceptual process for carrying out analysis; (2) using representation Model section) of the problem domain; (2) describe diagrams, which we call it Generic Conceptual Models these elements; and (3) organize all the elements of (GCMs), which do to presuppose any implementation the problem domain into a structure, by means of type, and (3) derive from the GCM, the best-suited CM which to define the associations that exist among (that is, a CM now used in SE, like DFD, use cases, etc.) these elements. for continuing with development according to the · In-Depth Analysis: The problem is studied in depth methods and standards usually used in SE. The following in this sub-activity in as much detail as required to sections present the components of the proposed develop the GCM. The goals of this sub-activity are approach in more detail. to: (1) check that the important problem elements have been identified; (2) describe the above 5.1. Generic Conceptual Model Development elements exhaustively; (3) clearly determine the Process associations among elements; and (4) distinguish the relevant elements for problem solving (which The proposed process is composed of two activities, as hereafter will be called key elements). All this shown in Figure 2(a). The two activities differentiate two information is set out in the GCM. states in analysis: a problem-oriented state and a Although described in detail in the next section, the solution-oriented state. only formal differences between the preliminary model The goal of the first activity, called Problem- and the GCM are related to the level of detail. This Oriented Analysis, is to understand the problem to be means that the preliminary model has the same solved and ends when the GCM, which represents the representational elements as the GCM, although such elements are fewer in number and type, and less take into account the problem elements that are not complex. compatible with the CM used (DFD, use cases, etc.) Having completed the Problem-Oriented Analysis before the problem is understood. Using the proposed and developed the GCM, the developer has gained approach, developer is encouraged to study all the extensive knowledge of the problem. Of the above possible problem perspectives, and record them in the knowledge, the key elements are important. The key GCM. Therefore, the lost of knowledge occurs when the elements, together with the associations established with problem has been understood, thus avoiding early other elements of the problem domain, determine the decisions about how to solve the problem at hand. data to be used, processes to be performed, etc., to provide a software-implementable solution to the 5.2. Generic Conceptual Model problem raised. This information is used in the Software System-Oriented Analysis, which is decomposed into the The CMs currently used in software engineering following sub-activities. have to be used exclusively, that is, mostly rule out the · Identification of System Type: The key elements, use of a complementary CM. In some cases, for example, as well as the elements with which they are when using a DFD, the use of supplementary notations, associated, are examined in this sub-activity to such as process specifications or even the determine what sort of software approach would be Entity/Relationship model, is permitted, although these best suited for implementing the solution to the are subordinated to the process diagram set out in the problem. The identification of the best-suited DFD. development approach (structured, object-oriented, The GCM proposed in this approach is based on etc.) is based on a joint evaluation of key elements, complementariness. Instead of using a representation as well associations and related elements, against schema that dominates the modelling process, three pre-established parameters. So as to rule out complementary representation schemas are used. developer subjectivity, the only permissible values Complementary means: (1) each schema supports the for the parameters are yes/no, which are easily others, recording information they do not represent and verified and map to response sets 0/1. The final (2) the information in one schema could migrate, that is, result is a numerical table, which is compared move from one schema to another without the GCM against an ideal standard table, associated with each losing information. Characteristic (1) is similar to what development approach. The closest matching happens in the above-mentioned DFD example; in terms approach is the recommended one for the subsequent of the same example, characteristic (2) would allow the software development process. E/R concepts (entities, relationships), for example, to be · Derivation of the Classical Conceptual Model: In represented in the DFD and removed from the E/R this sub-activity, the last of out proposal, the GCM is without losing information, which is impossible using translated to the CM used by the selected current CMs. The proposed GCM components are as development approach (structured, object-oriented, follows: etc.), which we call it ‘target CM’. This translation is · Element Maps: are consolidated or non- based on a set of rules that use the information consolidated knowledge representation structures, contained in the GCM to get a skeleton of the target belonging to a given knowledge domain or problem. CM. Element maps are variations on the conceptual maps, The target CM in the above sub-activity is simply an derived from the work of Ausubel on Learning empty template that makes use of the formal properties Theory and Psychology, later formalised by Novak of the target CM. This template can be refined by [25]. We use the term ‘element maps’ instead of entering more information in the target CM. However, ‘concept maps’, as it will be closer to the original this refinement is neither direct, nor can it be formalised, work, because ‘concept’ is an overloaded word in owing to the fact that the GCM cannot be interpreted SE. For example, ‘concept’ is used with the meaning directly in computational terms. of ‘data’ many times. When we refer to ‘element’, Therefore, going back to the metaphor, the developer we are talking about ‘static concepts’, as data, rules will have to select what knowledge to record in the target or facts, and ‘dynamic concepts’, as processes, CM and what to discard, that is, the developer will have events, and so on. to put on the “right glasses”. Once complete, the target Conceptual maps (in the sense of Psychology) can CM will have the same drawbacks as CMs developed be used to express and graphically represent directly, that is, some knowledge about the problem will concepts and associations between concepts as a have been lost and the target CM will be linked to a hierarchical structure. Element maps differ from given development approach. Nevertheless, there exists a conceptual maps on two essential points: (1) they are strong difference between filtering problem elements not necessarily structured hierarchically but with the current and the proposed conceptual modelling generally as a complex graph; (2) both the concepts processes. Using current process, a developer does not (elements in our approach) and the associations, which represent established knowledge in Lift conceptual maps, are likely to evolve over time as Is composed of the sub-activities Superficial Analysis and In-depth Analysis progress. · Dictionaries: are tabulated information representation schemas. Dictionaries have a set of Something? Doors Buttons Engine predefined columns that define what sort of knowledge is to be recorded in them. There are two Open Close Turn on main types of dictionaries: Turn off · Identificative Dictionary: is used during

Superficial Analysis. This dictionary merely Figure 3. Element map for the superficial analysis records the information required to recognise a element or association appearing while The element map on figure 3 shows only a small investigating the problem and to distinguish one amount of information about the problem, as usual in element or association from another. superficial analysis. It can support missing information, · Descriptive Dictionary: is used during In- when developer knows that something exists but she Depth Analysis. Its goal is to record negotiated does not know what is it. All the problem elements information about element and associations, that should be recorded in an identification dictionary, as is, information that all the participants in the shown in Table 1. Unknown elements should be recorded analysis process agree to be true. This also, because they are valuable information for later information is used to determine what users are problem understanding. looking for, that is, to identify the key elements that will later be used to derive the CM. Element Identification issues · Narrative Description: is natural language text that · Either the inside or outside buttons of describes the information recorded in the concept the lift. map and the dictionaries. The narrative description · Inside buttons are used for carry can be automatically derived from the element map Button people to a floor (people are inside the and dictionaries (although the result is not a literary lift). masterpiece), which offers some clear benefits for · Outside buttons are used for lift to go GCM validation. The text is very understandable for to a floor (people are outside the lift). end users and, as there is a bijective relationship Floor · Used by the lift to know in which between the narrative description and the other detectors floor it is situated. representation schemas, the comments and Something? corrections made by the users can be fed back into · Something should stop the lift! those schemas. … · … In Section 4.1 we introduced the concept of Table 1. Identificative dictionary preliminary model. As mentioned above, the preliminary model is a simplified version of the GCM, obtained after Figure 4 shows an (fragmentary) element map for the Superficial Analysis, which is composed of: (1) a the in-depth analysis activity, obtained evolving the element map –usually hierarchical and not generally a previous element map. Such a map usually does not graph–, (2) identificative dictionary and (3), in all cases, contain any unknown term, and associations are more narrative descriptions. The GCM output at the end of the precise than in superficial analysis. In-Depth Analysis differs from the preliminary model in that: (1) the element map is more detailed and is Lift Is composed of generally a graph, (2) the descriptive dictionary is used instead of the identificative dictionary and (3) the narrative description is optional and is usually excluded. The above-mentioned schemas can be better Floor detectors Doors Buttons Engine understood by means of an example, as the typical Tell us we are Start problem of developing a computer-based controller for a Turn on lift. Figure 3 shows an element map constructed during At floor Go-to floor the superficial analysis activity. It must be considered Implies to compare close that different developers may develop slightly different element maps for the same problem in early activities of the proposed approach. Figure 4. Element map for the in-depth analysis The above element map always has an associated select the approach they feel more adequate. This second descriptive dictionary, as shown (simplified) in Table 2. group should fill a questionnaire also, with several This dictionary is much more precise than the questions regarding their familiarity to structured and identificative dictionary, because it contains information object-oriented development approaches. of higher quality. Information in descriptive dictionary is For every case study, we have compared the CMs considered true for all stakeholders. obtained in the three approaches, and we evaluated: (1) how well suited to the problem is the target CM, that is, Element Description the CM output of the proposed approach; (2) the · There exists one button for each floor correctness of the target CM; (3) the time taken to · Several buttons can be pressed develop the target CM; and (4) the validity of the target Inside simultaneously CM. Button · Lift should move to the closest floor and The results obtained so far appear to support the go on with the next-closest floor until all following findings: floors have been visited. · The target CM was considered best suited only in Floor · Set in port #35 the floor number typical problems (problems with a very strong bias detector towards a given development approach). The … · … approach is very often erroneous when the problem Table 2. Descriptive dictionary is only slightly biased towards the structured or object-oriented approach. Additionally, without any Element maps and identificative and descriptive apparent reason, students tend to select the CM dictionaries can be tralated into a narrative description. (DFD, Use Cases, Entity-Relationship, etc.) with This translation is possible simply by reading the element which they are most familiar to solve any sort of map in a top-to-bottom, rigth-to-left manner. For (non typical) problem. example, Figure 4 can be read as: ‘Lift is composed of · The correctness of the target CMs is similar using floor detectors and doors and buttons and [a] engine. the proposed approach and the structured and object- Floor detectors tell us we are at [a] floor…’. This oriented approaches. This finding was foreseeable narrative description can be complemented with entries even before the study was run, as the syntactic from identificative or descriptive dictionaries. For characteristics of every CM restrict the possibilities example, using the descriptive dictionary of Table 2, it is of expression. Students have interiorised the rules of possible to make more precise the above narrative symbol combination for each CM (DFD, Use Cases, description, as it follows: ‘Lift is composed of floor Entity-Relationship, etc.), which means that the detectors and doors and buttons and [a] engine. Floor results are correct in most cases. detectors tell us we are at [a] floor. Floor detectors set · It takes longer to develop the target CM using the in port #35 the floor number’. proposed approach. This was another foreseeable Finally, note that elements (and associations) in point in view of the increased workload involved in element maps and dicctionaries can be several ‘things’ in subdividing analysis. However, the data are not the problem domain. They can be, for example, real conclusive. There was found to be a trend relating things (as ‘engine’), actions (as ‘start’), states (as ‘at problem complexity and students’ familiarity with floor’), signals (as ‘tell us we are’), etc. The proposed the problem to target CM development time. For approach tries not to assign problem elements to any similar complexities, the time taken to develop the class (except ‘element’ and ‘association’), because this target CM is more or less constant, irrespective of assigment implies many times an early (and possible how familiar the student is with the problem wrong) decision. beforehand. For the structured or object-oriented approaches, familiarity is inversely proportional to 6. Conclusions the time taken to output the CM. · The validity of the target CM is surprisingly greater The proposed approach is now in the process of being that the CMs constructed using structured or object- verified and refined. However, we have some oriented approaches. The reason appears to be that preliminary results, based on case studies completed by students gain a better understanding of the problem undergraduate and postgraduate students, that appear to by performing the sub-activities Superficial Analysis confirm the soundness of the approach. and In-Depth Analysis. Having a better Case studies have been carried out using both the understanding, they are able to create not only a proposed approach and the classical development syntactically correct, but also a semantically approaches (structured and object-oriented). Students coherent target CM. Using structured or object- were divided in two-sized groups. The first group should oriented approaches, students tend to subordinate use the proposed approach. The second group could understanding to representation, outputting semantically ambiguous, albeit syntactically correct, 11. A.M. Davis, Software requirements: Objects, CMs. functions and states. Prentice-Hall International, Finally, it should be noted that the proposed 1993. approach requires more experimentation and refinement, 12. P. Jalote, An integrated approach to software especially with regard to: (1) the identification of the engineering. Springer-Verlag, 1997. system type, as the results obtained have been found to i-34014. L.M. Northrop, Object-oriented be far from satisfactory; and (2) the workload induced in development. In: Software Engineering, IEEE the analysis task. Computer Soc. Press, Los Alamitos, USA, 1997. This refinement is to be done by continuing to 13. L.M. Northrop, Object-oriented development. In: research the properties of the systems built according to Software Engineering, IEEE Computer Soc. Press, the structured and object-oriented approaches, and Los Alamitos, USA, 1997. develop new standard tables that more faithfully 14. N. Juristo, A.M. Moreno, Introductory paper: represent the features of these system types. It is needed Reflections on conceptual modelling. Data and to study the decomposition of the proposed approach Knowledge Engineering, no. 33, 2000. also, trying to minimize the steps required to perform the 15. D. Beringer, Limits of seamless in object oriented analysis task. software development. In: Proceedings of the 13th International Conference on Technology of Object 7. References Oriented Languages and Systems (TOOLS), Versailles, France, 1994. 1. SWEBOK. Guide to the Software Engineering Body 16. P. Loucopoulos, V. Karakostas, Systems of Knowledge. http://www.swebok.org. requirements engineering. McGraw-Hill, Berkshire, 2. Motschnig-Pitrik R., The of parts versus 1995. aggregates in data/knowledge modelling. 17. H. Kaindl, Difficulties in the transition from OO Proceedings of the CAiSE'93, number 685 in Lecture analysis to design. IEEE Software, vol. 16, no. 5, Notes in Computer Science, Springer Verlag, Paris, 1999. France, June 1993. 18. M. Jackson, Software requirements and 3. A. Borgida, Knowledge representation, semantic specifications. A lexicon of practice. Addsion- modelling: Similarities and differences. In Entity- Wesley, 1995. Relationship Approach: The Core of Conceptual 19. M. Jackson, Will there ever be software Modelling, H. Kangasalo (ed.), Elsevier Science engineering? IEEE Software, vol. 15, no. 1, 1998. Publishers B.V., 1991. 20. A. Davis, K. Jordan, T. Nakajima, Elements 4. J. Mylopoulos, A. Borgida, E. Yu, Representing underlying the specification of requirements. Annals software engineering knowledge. Automated of Software Engineering, Balzer Engineering Software Engineering, no. 4, 1997. Publishers, 1997. 5. G. Schreiber, H. Akkermans, A. Anjewierden, R. de 21. D. Coleman, P. Arnold, S. Bodoff, C. Dollin, Object- Hoog, N. Shadbolt, W. Van de Velde y B. Wielinga, oriented development: The fusion method. Prentice- Knowledge engineering and management: the Hall, 1994. CommonKADS methodology. MIT Press, 1999. 6. J.D. McGregor, T. Korson, Object oriented design. 22. D. Champeaux, D. Lea, P. Faure, Object oriented Communications of the ACM, vol. 33, no. 9, 1990. system development. Addison-Wesley, New York, 7. F. Bonfatti, P.D. Monari, Towards a general purpose 1993. approach to object-oriented analysis. In: 23. R. Wieringa, Object-oriented analysis, structured Proceedings of the International Symposium of analysis, and Jackson system development. In: F. van Object Oriented Methodologies and Systems, Assche, B. Moulin, C. Rolland (eds.) Proceedings of Palermo, Italy, 1994. the IFIP WG8.1 Working Conference on the Object- 8. G.M. Høydalsvik, G. Sindre, On the purpose of Oriented Approach in Information Systems, North- object oriented analysis. in: Proceedings of the Holland, 1991. Conference on Object Oriented Programming, 24. J. Mylopoulos, L. Chung, E. Yu, From object- Systems, Languages and Applications, New York, oriented to goal-oriented . USA, 1993. Communications of the ACM, vol. 42, no. 1, 1999. 9. S. McGinnes. How objective is object-oriented 25. D. Novak, D. B. Gowin, Learning to learn. analysis? In: Proceedings of the CAISE’92 Cambridge University Press, 1984. Advanced Information , 1992. 10. B. Henderson-Sellers, J. Edwards, The object oriented systems life cycle. Communications of the ACM, vol. 33, no. 9, 1990.