Paradigm and Software Engineering
Erek Göktürk
M. Naci Akkøk
Information Design Group, Dept. of Informatics, University of Oslo, Norway.
[email protected]
Information Design Group, Dept. of Informatics, University of Oslo, Norway.
[email protected]
Abstract The word paradigm is used, defined and re-defined in many disciplines (including software engineering) to the degree that its meaning has become overloaded and hence vague. In this paper, we look at its various meanings and offer a working definition for use in software engineering. We also offer an explanation of the role of paradigm in software engineering, claiming that the choice of modeling/design paradigm has profound effects on the quality of both the software process and its product. We propose that paradigms be reified into artifacts and consciously used to improve software development, and recommend that more emphasis be put towards understanding their nature in depth. Keywords Software Engineering – software engineering paradigms – software quality – process improvement.
1. Introduction The last decades witnessed a proliferation of the use of the term paradigm in connection with many fields, resulting also in the proliferation of its definitions. Software Engineering is one of the fields that use the term extensively. Views like one paradigm being better than the other are not uncommon in software engineering, where the yardstick of comparison is often relative improvements in the process by which software is produced, implying also relative improvements in the quality of the software produced. One issue in using the term paradigm in relation to its effects on the software development process and/or software quality is obvious: when a term has as many different definitions as the term paradigm has, the term is most likely not well defined. Even when we assume one specific definition, there is still an issue: the exact effect of choosing a specific paradigm upon the software engineering process or the resulting software is neither empirically studied, nor cognitively grounded, and not even theoretically or philosophically defined.
In this paper, we try to remedy the situation first by extracting a plausible definition for the concept of a paradigm through looking at the term’s various definitions as well as its history of use in general and in software engineering in particular. We then reason through to its potential role in software engineering, essentially formulating hypotheses related to why and how a paradigm influences the process and product of software engineering. We conclude by suggesting that a paradigm may intentionally be reified into an artifact of software development and used consciously to amplify its positive (potential) effects upon the software engineering process. We claim that turning the paradigm into a concrete software engineering artifact consciously will also facilitate evaluating its actual effects within a project and across software engineering projects.
2. What is “Paradigm”? An etymological analysis shows us that the word comes from the Latin word ‘paradigma’, and appears in Greek as ‘paradeigma’, whose English translation is ‘example’, or as its earlier form ‘paradeiknunai’. The prefix ‘para-‘ meaning ‘alongside’, and ‘deiknunai’ meaning ‘to show,’ so the two words together sound as ‘alongside shown’ or ‘what shows itself beside’ [1].
2.1 Tracing the Meaning Back in History The word “paradigm” surely escaped from the laboratory of philosophers, mostly due to the fact that its meaning was vague. Plato and Aristotle are the oldest sources who have left written discussions that include aspects of the nature of exemplary relations and the example, the paradigm. Agamben [1] reports work of Victor Goldschmidt [2], in which Goldschmidt discusses that the paradigmatic relation in the context of Plato’s works is not of inductive nature, and works between a singular example, the paradigm, and the object class that the paradigm makes intelligible. Aristotle, in Rhetoric [3] 1356b, states that the paradigm is different from both deduction, which goes from the universal to the particular, and induction, which goes from particular to the universal, in that the paradigm (example) goes from the
particular to particular. Aristotle further states that the relationship between the paradigm and the class of objects is an anti-symmetric one, the paradigm being more “knowable” than the objects it gets compared to. To give an example to this notion of paradigm, and how its conception might differ from person to person, think of the most typical kind of cheese for you. we guess many of us, in some point of our lives, have been confronted by a kind of an edible substance which was claimed to be a kind of “cheese” as well, yet was out of our conception of cheese, that is our typical cheese and the class generated by it. It’s only more astonishing to see that this imaginary conception of the typical cheese kind gets twisted to include the new kind of cheese if we like it and choose to regard it as “cheese”, and each person has his/her conception of what is cheese, a personal cheese paradigm. The cheese paradigm is what we use to define the class, but it, as itself, isn’t an element of it. This human dependency of the “paradigm” appears as a recurrent theme, sometimes even regarded as the intangible aspects of it. The concepts of example and analogies were not a very favorite concept among the philosophers up until the 20th century. The words entered to the popular vocabulary through the works of Michel Foucault, and more prominently through works of Thomas Kuhn. Unlike Foucault, who uses the term paradigm but never defines it, Kuhn uses the word paradigm in explaining his thoughts on the philosophy of science, and attempts at the following definition [4]: A paradigm is “...a constellation of concepts, values, perceptions and practices shared by a community which forms a particular vision of reality that is the basis of the way a community organizes itself. ” The word paradigm is used in many meanings in his book, but this definition of paradigm got so immediately popularized and applied onto everything with virtually every meaning that seem closer enough (!) to this definition, that even Kuhn himself admitted that his usage of the word was vague, suggested the word exemplar instead of the word paradigm and suggested an elaboration of the meaning. Among other reasons, its popularization is also connected to the fact that the paradigm in Kuhnian sense provides the external justification, a strong excuse for not being rigorous. This can especially be observed in social sciences: the belonging to a group of people with similar research and world view, which can be named as working in a particular paradigm, is all that’s enough to immediately justify or argue for the presuppositions to build research upon. When we take a look closer to the Kuhnian sense of the word paradigm, we can see that his definition virtually bonded it with only one of its specific philosophical appli-
cation, thereby narrowing the meaning of the word paradigm to a specific paradigmatic relationship. What he calls paradigms in science are just the typical singularities (examples) in the ways of practicing science. Since everybody has a personal way of practicing science, these examples that Kuhn calls paradigms are paradigms (examples) that define categories over this set of personal attitudes towards science, by being typical elements of these categories. Thus suggestion of the word exemplar and his original use of the word paradigm by Kuhn himself is far from being an arbitrary naming, but is an act of referring and relating to a known concept. If one looks up the meaning of the word ‘paradigm’ from a dictionary, one of the meanings turns out to be “a model”. An interesting question is how this meaning appeared and became attributed to the word paradigm. The answer most probably lies in its being implied both in Foucault’s and Kuhn’s work. To give an example, in the works of Foucault, the panopticon of Jeremy Bentham, which is an architectural surveillance machine, not only serves as an historical artifact, but also as the a paradigmatic structure, an architectural “model” which also can be used for understanding power relations [5]. So one can conjure similarities between various parts of the panopticon and a power structure to analyze it, which implies the panopticon as a model as well. In Kuhn’s work, the paradigm includes the metamodel of the representation tools and models of the subject matter used by a specific scientific community, and the paradigm easily gets confused to be this meta-model, which is actually a part of it from a Kuhnian perspective. Taking the cheese paradigm example also into account, one observation is that some things that we perceive as paradigms have the properties of a model, but some paradigms do not. What is similar and different between these two notions of paradigm is a question that should be addressed, and also how they relate to each other. This might lead to a model of multi-paradigm structures.
2.2 Paradigm, Ontology, and Epistemology Whether we confine ourselves to the meaning of the word paradigm as a model or not, two subjects of philosophy are related to it: epistemology and ontology. It must also be added that epistemology and ontology themselves are related as well. Many definitions for ontology exist. An exemplar of one category of definitions is the theory or the study of objects and their relationships. Although this definition seems very intuitive and easy to grasp, it’s flawed in its drawing onto an ontological assumption of objects being present. An operational definition that does not refer to objects is that an ontology is a specification of a conceptualization [6]. The fact that this definition also needs to be coupled by the definition of conceptualization makes it clear that defining
what is ontology is a very hard task. The ontology seems to be the answer to this question: what is out there? The question of what is out there can obviously be answered by a specification, which depends on the observer with respect to whom “out there” is defined, and the ontology-maker who constructs the specification. Philosophers take this question as being about what exists in the one and only universe that also includes the observer and the ontology-maker, and hence become chilled by references to multiple ontologies1, which is a very common expression especially in Artificial Intelligence in which an ontology bases upon what can be representable. But one should also observe that when this concept of what is representable gets applied not to a system but a human, it derives the philosophical point of view, and “an” ontology becomes one attempt at representing “the” ontology. Whether it’s “the” ontology or “an” ontology, the truth or fidelity of such a representation, and its knowability, is the subject of yet another branch of philosophy which studies knowledge: epistemology. It attempts to answer the basic question: what distinguishes true (adequate) knowledge from false (inadequate) knowledge? Having mentioned the ontology and epistemology, now we may turn back to the question of the relation between the paradigm and the ontology and epistemology. First of all, if ‘paradigm’ is also something out there, it’s definitely a part of ontology in philosophical sense, and an assessment of how much we can know about it would depend on the epistemological stance we might take. If it is a class formation operator, defining a class by being the typical example, then paradigmatic relationships should also be parts of ontologies, whether “an” or “the”, and should be studied just as much as ‘part-of’ and ‘kind-of’ relationships gets studied. How the paradigm relates to our ability to relate to “adequate” knowledge is another open question.
2.3 Paradigm Creeps into Computing Kristen Nygaard, one of the fathers of the Simula language and what is today known as the object-oriented paradigm, mentioned more than once that it took about 20 years for the object-oriented paradigm to establish2, except that there is no mention of the term paradigm from 1967, when SIMULA 67 was introduced [7], and none of his professional acquaintances seem to remember him actually using the term paradigm until much later.
1
2
Our thanks goes to Michael Biggs, who was in University of Hertfordshire, UK at the time this paper was written, who pointed to this “chilling effect” as a feedback for one of the authors’ presentation in CEPHAD’04 conference, Bornholm, Denmark. Private conversations with Kristen Nygaard.
It is difficult to establish the exact date when the term paradigm was first used in software engineering, but it seems it started within the context of Smalltalk [8] rather than Simula around 1972. This is about 2 years after the publication of the revised edition of Kuhn’s work that triggered the widespread use of the term paradigm. Thus, it is very likely that the term was first used in its Kuhnian sense in software engineering as well. Alan C. Kay himself refers to the introduction of the “new” computing principles through Smalltalk as “a new Kuhnian paradigm in the same spirit as the invention of the printing press” [9]. This sounds as if we know what paradigm means in the context of software engineering despite the fact that the word has come to have a variety of different meanings in other disciplines. Unfortunately, this doesn’t seem to be the situation. We have searched “software engineering paradigm” in Google (www.google.com), and out of five results in the first ten, we extracted six different meanings, some from how the word paradigm was used, and some as direct definitions: trend [10]; method, procedure, generalization of process [11]; methodology [12]; a technique; the process model (this was actually presented as a definition of the word paradigm) [13]; and an approach to software design and programming (this was also a definition) [14]. Here are some more examples of usage from various papers in the field of computing: “high level paradigm”, “programming paradigm”, “design paradigm”, “object-oriented paradigm”, “constraint satisfaction paradigm”, “probability theory is perhaps the best understood paradigm”, “the paradigms used for temporal reasoning”, “xxx framework enables a new paradigm for Internet services”, “most basic algorithmic paradigms in computational geometry”, “intrusion detection paradigm”, “employee-manager-salary paradigm”3. Obviously some of these fit into the word’s meaning as an exemplar, model, or its meaning in Kuhnian sense. Such a broad meaning and the use of adjectives as “most basic” or “best understood” to qualify the word paradigm, or the concept of “enabling a new paradigm” are nevertheless interesting, but the variety suggests a confusion, both for the individual software engineer or designer, and also for the software engineering community. Thus the question stands: what does “paradigm” mean in the field of Software Engineering? We believe that the answer to this question is not so trivial, and we will not attempt to give a final all-encompassing definition in this paper. It’s the subject of one of our ongoing studies to answer this question and arrive at an inclusive definition of the word “paradigm” based on philosophical and cognitive aspects, which we hope will uncover the essence needed to 3
References are not given for brevity, simply search “paradigm” on http://citeseer.ist.psu.edu/ and look at the first couple of papers.
relate all definitions, or uses of the word. Still, we offer a working definition of paradigm (actually an attitude) that has utility value for software engineering in the next section.
3. Current Attitude towards Paradigms For the rest of the paper, we will assume the following definition which is related to model building: A paradigm is an ontology of the world, which necessarily includes some representational tools and methods for an observer to build models. We speak of “an” ontology, to mean that it includes a subset of what is representable, and this representative power is definitely related to the representational tools and modeling methodologies, and their relation to the observer, or in other words the model builder. This meaning of the word paradigm is not very far from any of the meanings mentioned in the previous sections, but it is crafted for the discussion of the effects of paradigms in software engineering, and it is closer to the meaning of paradigm being a model, since the definition suggests that different paradigms would act as meta-models for software modeling. We also keep the meaning of paradigm in Kuhnian sense, that the paradigms we are going to mention represent some shared attitude towards software modeling and design among a group of theoreticians and practitioners, or at least did at some point in time. The major software modeling and design paradigms that evolved in the course of history of computing can be named as the procedural paradigm, the data-hiding paradigm, the data-abstraction paradigm, and the object-oriented paradigm. A brief description of these can be found in the course notes of a course on object-oriented programming at the Louisiana State University [15]. There are also newer ones, which seem to have the potential to be regarded among the major ones in future classification. The component-based paradigm, the aspect-oriented paradigm, and the agent-oriented paradigm are amongst these. We will take the component-based and agent-oriented paradigms as “newer paradigm” candidates in the context of this paper, but the ideas should easily be carried over to a discussion of aspect-oriented paradigm as well. The procedural paradigm was the first to come. Its focus is on the algorithm to be used for particular computational tasks. The data-hiding paradigm puts the emphasis on the data organization, introduces the notion of modules, and the design process consists of partitioning the software in such way that the data becomes hidden in the modules. The dataabstraction paradigm focus upon the types and operations defined on the types. The object-oriented paradigm builds upon the data-abstraction paradigm, and puts more emphasis on the commonality between types using inheritance and polymorphism. The component-based paradigm attempts to follow the successful example of the integrated circuits of
electronics engineering, drawing upon enhanced reusability through building software by integrating preferably COTS (Commercial Off The Shelf) software elements. The agentoriented paradigm [16] divides the software into independent and communicating entities called “agents”, thereby focusing on design of individual goal-oriented “agents”, and an environment for these agents to be situated in. The programming languages and the modeling/design paradigms are tightly coupled. The relationship is of chicken-and-egg nature: sometimes the need for a programming language arises for better implementation of models/designs in specific modeling/design paradigms, and sometimes the constructs of a programming language gets applied in the modeling, evolving into a paradigm, and always the programming language and the paradigm gets affected by each other. Even some programming languages support multiple modeling paradigms, such as C++, they tend to be remembered by the modeling paradigm they most frequently get used in accordance to, such as the objectoriented paradigm for the C++ language. The separation of component-based and the agentoriented paradigm from the older paradigms, and their being mentioned as “new” implying immaturity is partly based on the fact that they don’t have direct programming language counterparts. Models/designs in both of these paradigms get implemented using programming languages previously created to support other paradigms, esp. Java and C++ which puts most emphasis on object-orientedness. We will come back to this language mismatch in the next section, when we discuss the effects of the paradigm as an actor in software engineering. With respect to these paradigms mentioned in this section, the work done in current research and practice in the field of software engineering can be categorized to belong to one of two groups. In the first group of work, one confines oneself into the realm of one specific paradigm. In the other group of work, the focus is on application of one paradigm onto a modeling/design problem, using the representational and methodological toolset of another paradigm. This last can especially be easily observed in the case of component-based and agent-oriented paradigms, which lack their supporting programming languages and an explicit definition of their respective paradigms, and which then tend to borrow their representational tools for the objectoriented paradigm such as the UML [17]. See also [18] for a discussion of object-oriented paradigm based approaches to representational issues in agent-based software modeling/design paradigm, and for an attempt to create a representational tool which would not be based on objectoriented concepts and representational tools. The degree of fitness of object-oriented tools to component-based software engineering is also discussed in chapter 6 of Akkøk’s doctoral thesis [19].
Both of these approaches, either confinement into one specific paradigm or trying to model/implement one paradigm using the others, do not touch on the concept of the paradigm itself, and can act only as parts of an operational definition for software modeling/design paradigms. What is missing is a theory explaining the nature of paradigms, and it is the absence of which we want to draw attention upon via this paper.
4. Paradigm as an Actor in Software Engineering Need help in exploring and changing your paradigms for a brighter future? Contact us today!4 Since Kuhn has written his book [4], it has become almost the standard practice for new developments to be introduced as the new cure for the blinding effects of the older, more established paradigm, even though Kuhn points to the fact that the lifecycle of a discipline is cyclic, one paradigm following another. Nevertheless, the need for a panacea (the cure of all pains) in any specific discipline is so pressing that, almost as a rule, any new paradigm is regarded as a relief to all (mortal) practitioners and/or theoreticians. Software engineering is a field no different. If we look into the history (which is only about three-four decades back in case of the every young discipline called software engineering, starting approximately with the NATO software engineering conferences [20, 21]), we see that the search for a silver bullet [22, 23] was a constant one, and claimed to be silver bullets all oxidized and vaporized as more experience accumulated on the new paradigm thought at that time to be as the one, and brand new well polished silver bullets got introduced only to create greater enthusiasm, and only to be pushed aside by newer and newer ones. One of the most recent (and widely accepted) examples to a “rescuer new paradigm” in software engineering is the object-oriented paradigm, which has been claimed to be the ultimate solution without convincing empirical evidence to that effect. The advertisements for the component-based paradigm seem to be also of a similar attitude, creating something like a deja-vu. Although the object-oriented paradigm is far from being packed away into the dusty shelves of the history of computing, already there exist new paradigms to claim the crown, most notably the component-based paradigm, the aspect-oriented paradigm and the agent-oriented paradigm. We may also note that there exist other approaches, such as
4
Taken from the website of a management consultancy company. Reference is not given, since we don’t want to advertise, but if you do want to find the page and the company, try searching the Web using Google.
agile methods, whose being a paradigm or not is not very clear to the authors. But taking into account that in practicing using these three paradigms one uses the representational tools and approaches from other paradigms, especially the object-oriented, it’s tempting to ask the question that given any two so called paradigms, what makes them different? So is the so-called component-based paradigm indeed a different paradigm from the object-oriented? Is there a comparative scale between paradigms, ranging from "can be modeled using one another", as in the case of component-based and object-oriented, to "inherently different, incompatible"? Furthermore, does or can these relations work only one way: Can one paradigm be modeled via another but not vice versa? For the software modeling/design paradigms, the set of differentiating properties might be found in the relation of the paradigm to the concept of ontology, as discussed in section 2 and exemplified below. This is because software is essentially an executable model, and it is the result of a series of (mechanical and/or mental) transformations of models as suggested in the definitions of the concept of a language and modeling in sections 5.1 and 1.1 of Akkøk’s work [19] as represented by Figure 1. The act of modeling starts with a mapping between the elements from “the” ontology, what is out there in the universe, to “an” ontology, the ontology of the modeling/design paradigm. Thus the paradigm determines what is representable, and how easily. To give an example, one of the reasons why the object-oriented paradigm is so intuitive at first is that humans have the tendency to differentiate objects, yet trying to model everything with objects also create problems, such as the need for reifying some processes. The data-abstraction paradigm maps “the” ontology onto types and operations, the component-based onto components, and agent-based onto agents and communication. Is one paradigm better than other? If we think of the mapping between “the” ontology and the ontology of paradigms, it’s clear that we should expect some paradigms suit some tasks/domains better. It’s an open question to find which paradigms relate to what kind of tasks, and how to assess the suitableness. If one paradigm suits one task better than others and supposing we have the grounds to claim such a normative statement, what about complex tasks, constituent tasks of which might require multiple paradigms? A solution to this combination of paradigms might be “by modeling one with the other, thereby exporting the conceptualization done by one paradigm to the other”, but since we don’t know the answer to the question if there exist a scale of compatibility, and the positions of the paradigms in such a scale with respect to others, we cannot be sure that this claim constitutes as an solution or not. We believe that the solution to multipleparadigm modeling lies in a theory of paradigms, which
would constitute of meta-paradigmatic statements and would act as the common grounds and norms to choose and to combine paradigms, or to show that they are not combinable.
Figure 1. Model transformation in Model Driven Development (MDD)
The compatibility of paradigms question is also related to the programming language - modeling/design paradigm coupling, especially in the case of paradigms that do not have their own programming languages, namely the component-based and the agent-oriented paradigms. What do we pay in using a programming language that is created to support a different paradigm, say the object-oriented (like Java, C++ or Smalltalk), when we use them in building components or agents? From the translational point of view, this means that at least in the last translation from nonexecutable representational forms of the model to the executable form, if not before in translations between nonexecutable translations, we model one paradigm using another, thereby change paradigms. This suggests information loss, increased probability of introducing errors etc. Can and do we justify what we are doing? There is also the “problem” that the ones who are creating the first mapping from “the” ontology to the ontology of
the paradigm, and the ones who are translating one representational form to another to end in an executable final representation are only human. This aspect of the paradigm is mostly neglected, and studies on understanding the cognitive load created on the designer/model builder, and designer’s/model builder’s cognitive toolset should become a study area. There is need for more cognitive/empirical studies on the question of how the human relate to the suitability of the paradigms to the tasks problem. How such studies should be conducted is another open question. Finally, we ask what the role of a paradigm is in software engineering. With the definition we have proposed in this paper, its role is already set through for example OMG’s [24] MOF [25] that can be interpreted as an attempt to define “an” ontology of modeling languages – i.e., modeling language “things”, relationships between them and the rules governing these languages, except that the ontology would be limited to reflect one specific modeling approach (like the object-oriented approach) in any given software engineering project. Alternatively, one could have a paradigm defined per phase or activity of the software engineering life-cycle. In essence, what we claim is that a paradigm’s importance in software engineering is parallel to choice of conceptualization and communication language in a software engineering project, and that it can be done explicitly and defined formally. One last comment in order to explain the importance of choice of paradigm in software engineering: if choice of paradigm is like choice of conceptualization/communication language, then according to the SapirWhorf thesis [26, 27], it is of utmost importance because choice of language decides to a large degree what we see, how we see and conceptualize what we see, and how we reason. Since software engineering activities like analysis, design and implementation are communication and reasoning-intensive activities, setting out with a wrong or illdefined paradigm would be very unlucky indeed.
5. Conclusion - Towards Conscious Usage From a philosophical perspective, the paradigm used in the software process should have profound effects on the success of the process and the quality of both the process and the product. The effects of the paradigm on the quality of the process is mostly due to the cognitive aspects of the paradigm: It eases some representational tasks and makes some others harder, thereby having direct influence on the cognitive load the process has on its implementers. The effect on the end-product is not only due to the effects on the process, but also due to the software engineering paradigms’ frequent inclusion of a computational ontology: the basic elements of computation and their relations. Like many questions posed in this paper are, the question of how farfetched the effects of paradigms in software life-
cycle are is also still open. To address these questions, we argue for reifying the paradigm into a cognitive artifact [28] to be included in the software engineering toolset, in order to pave way towards understanding various paradigms’ both threats and promises, to avoid the negative effects and harness the potentials. To reify the paradigm as an artifact, and to focus on its effects, a definition of the paradigm sufficiently grounded, covering the philosophical aspects as well as the cognitive ones and their relations is needed. In this paper we presented a direction and first results, and we believe this direction will prove to be a fruitful one for software engineering.
6. References [1]
G. Agamben, "What is a Paradigm?," available online at http://www.egs.edu/faculty/agamben/agambenwhat-is-a-paradigm-2002.html, last visited April 29th, 2004. [2] V. Goldschmidt, Le paradigme dans la dialectique platonicienne. Paris: Presses Universitaires de France, 1947. [3] Aristotle, "Rhetoric," available online at http://www.public.iastate.edu/~honeyl/Rhetoric/index. html, last visited April 29th, 2004. [4] T. S. Kuhn, The Structure of Scientific Revolutions, 3rd ed: University of Chicago Press, 1996. [5] M. Foucault, Surveiller et Punir: Naissance de la Prison. Paris: Gallimard, 1975. [6] T. R. Gruber, "A translation approach to portable ontology specifications," Knowledge Acquisition, vol. 5, pp. 199-220, 1993. [7] A. C. Kay, "The Early History of Smalltalk," available online at http://gagne.homedns.org/~tgagne/contrib/EarlyHistor yST.html, last visited March 29, 2004. [8] Smalltalk Organization, "Smalltalk official site with tutorial," available online at http://www.smalltalk.org/, last visited March 29, 2004. [9] K. Nygaard, "How Object-Oriented Programming Started," available online at http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_ MAPPE/F_OO_start.html, last visited March 29, 2004. [10] V. Radonic, M. Krieger, and J.-P. Corriveau, "A response oriented paradigm for software engineering," presented at 1994 Conference of the Center for Advanced Studies on Collaborative Research, Toronto, Ontario, Canada, 1994. [11] I. Crnkovic and M. Larsson, "Component-based Software Engineering - New Paradigm of Software Development," presented at MIPRO 2001, Opatija, Crotia, 2001.
[12] S. O'Malley and S. A. DeLoach, "Determining When to Use an Agent-Oriented Software Engineering Paradigm," presented at Second International Workshop On Agent-Oriented Software Engineering (AOSE2001), Montreal, Canada, 2001. [13] "An Abbreviated Software Engineering Glossary," available online at http://www.rspa.com/spi/glossary/, last visited April 24th, 2004. [14] "Fact Guru, Object-Oriented Software Engineering Knowledge Base," available online at http://www.site.uottawa.ca:4321/oose/index.html, last visited April 24th, 2004. [15] L. T. Blanks, "Web-notes for CSC 3370 - Introduction to Object Oriented Programming Using JAVA," available online at http://bit.csc.lsu.edu/~ltb/cd3370sum01/, last visited March 21, 2004. [16] N. R. Jennings and M. Woolridge, "Agent-Oriented Software Engineering," in Handbook of Agent Technology, J. Bradshaw, Ed.: AAAI/MIT Press, (to appear). [17] A. Dogru and I. Altintas, "Modeling Language for Component Oriented Software Engineering: COSEML," presented at The 5th Biennial World Conference in Integrated Design & Process Technology, Addison, Texas, USA, 2000. [18] R. Choren and C. Lucena, "ANote: A Modeling Languagae for Agent-Based Systems," available online at http://www.teccomm.les.inf.pucrio.br/esac2003.1/files/arq/esac_18Mar.pdf, last visited April 24th. [19] M. N. Akkøk, "Towards the Principles of Designing Diagrammatic Modeling Languages: Some Visual, Cognitive and Foundational Aspects," in Institute of Informatics, Mathematics and Natural Sciences Faculty. Oslo: University of Oslo, 2004. [20] P. Naur, B. Randell, and (Editors), "Software Engineering: Report of a conference sponsored by the NATO Science Committee," Garmisch, Germany, 711 Oct. 1968, 1969. [21] B. Randell, J. N. Buxton, and (Editors), "Software Engineering Techniques: Report of a conference sponsored by the NATO Science Committee," Rome, Italy, 27-31 Oct. 1969, 1970. [22] F. P. Brooks, The Mythical Man-Month: Essays on Software Engineering. Reading, Mass.: AddisonWesley Pub. Co., 1975. [23] F. P. Brooks, "No Silver Bullet," presented at IFIP'86, 1986. [24] OMG, "Object Management Group (OMG) Home Site," available online at http://www.omg.org/, last visited March 20, 2003. [25] OMG, "Meta-Object Facility (MOF) V1.4 Specification," available online at
http://www.omg.org/technology/documents/formal/mo f.htm, last visited April 29, 2004. [26] B. L. Whorf, "Science and Linguistics," Technology Review, vol. 42, pp. 229-31, 247-8. Also in B. L. Whorf (1956): Language, Thought and Reality (ed. J. B. Carroll). Cambridge, MA: MIT Press, 1940.
[27] E. Sapir, "The Status of Linguistics as a Science," presented at E. Sapir (1958): Culture, Language and Personality, 1929. [28] D. A. Norman, Things That Make Us Smart: Defending Human Attributes in the Age of the Machine. Addison Wesley Pub. Co., 1993.
