Extended Abstract: Towards a Semiotics of Object- and
Aspect-Oriented DesignJames Noble1, Robert Biddle2, Ewan Tempero3, and David Pearce11 Computer ScienceVictoria University of WellingtonNew Zealand2 Human-Oriented Technology LabCarleton UniversityOttawa, Canada3 Software EngineeringThe University of AucklandNew ZealandAbstract. Object-oriented design is based on the argument that objects in a pro-gram act as a simulation of objects in the real world. This paper will providea semiotic account of object-oriented design patterns, treating an object as asign comprised of some part of the real world, its realisation in the program,and the programmers intent about the program design (that the object model theworld). The paper will then go on to discuss the developing discipline of aspect-orientation affects the representational discourses of object-orientation. Consid-ering the semiotics of object-oriented design can address these quetsions, bothhelping programmers design their programs, understand the way their designs“work”, and informing the general philosophy of computer science.1 IntroductionAn object-oriented design is a “description of communicating objects” [13, p.3]. In thispaper, we will provide a semiotic account of object-oriented design. Semiotics is thestudy of signs in society, that investigates the way meaning is carried by communica-tion, treating communication as an exchange of signs. When semiotics began in theearly years of the last century, most work was concerned with conventional signs —first speech, and then writing [11]. Since then, the scope of semiotics has widened tocover all kinds of signs, to the point where semiotics underlies much of structuralistand post-structuralist literary theory, film studies, cultural studies, advertising, and eventhe theory of popular music and studies of communications between animals (zoosemi-otics) and within them (biosemiotics) [21].2 SemioticsSemiotics, as defined by Saussure [8], is the study of signs in society; where a signis “something standing for something else” [11]. Since Saussure, semiotics has beenapplied to a wide range of different kind of signs, and for a range of diverse purposes[1, 7, 10–12, 6].For the analysis in this paper, we will follow Eco [11] and adopt the Peirce’s triadicmodel of the sign [19] shown in Fig. 1.representamen referentintrepretantFig. 1. Peirce’s SignPeirce’s sign is a three-part relationship between a representamen, a referent and ainterpretant. The representamen is some phenomenon that an individual can see, hear,sense, or imagine. The referent (Peirce’s term is object: we shall use referent in thisarticle to avoid confusion between semiotic objects and the objects in object-orientedprograms) is the a concept or entity to which the referent refers: the “something else”for which the referent stands. Finally, the interpretant is the mental concept that therepresentamen produces.For example, consider the English word “chocolate” as a Peircian sign. The spokenor written word “chocolate” is the representamen; a solid compound of cocoa beans,cocoa butter, sugar and milk is the referent; the resulting mental concept of chocolatein the reader or hearer of the word is the interpretant.3 Object-Oriented DesignA program execution is regarded as a physical model, simulating the be-haviour of either a real or imaginary part of the world.Object-Oriented Programming in the BETA Programming Language.Ole Lehrmann Madsen, Birger Møller-Pedersen and Kristen Nygaard [15]This quote from Lehrmann Madsen et al. outlines the core principle underlyingobject-oriented design, that an object-oriented program simulates (or models) the world.To model a farm, for example, a program could have a Bovine class, where each objectrepresented a cow; an Ovine class where each object represented a sheep; a Porcineclass where each object represented a pig, and so on [1, 2, 17, 16]. Following a Peir-cian approach we can take this simulation or modelling relationship to be semiotic: thatis, we can treat a program as a sign where the representamen is the set of objects andclasses in the program; the referent the set of entities in the world that the programmodels, and the interpretant the concept that a particular program models a particularreal or imaginary subpart of the world [2]. For an object-oriented program, we go fur-ther, taking a particular object in the program as a repsentamen; the part of the worldthat object models as a referent; and the idea that a particular object models a particularpiece of the world (that the Bovine instance at memory location OxDEADBEEF modelsDaisy the cow in the field somewhere) as the interpretant of the sign. (see figure 2).objectobject−models−entityentity in the worldFig. 2. An Object as a Sign4 Implicit SignsUnfortunately the question of what is an object in the program and an object in the worldare rarely so simple. Figure 3 shows the almost generic diagram of students attendinguniversity courses. Versions of this diagram are found in many publications on object-oriented design [18, 3, 4, 20, 9]. Many students attend many courses; Courses have acourse code, a title string and a teacher; students have numbers and (reluctantly, at leastat our university’s registry) names.**PrerequisiteCourseCodeTitleFeeWorkloadFacultyNameOffice*NameNumberStudent**Attends*Amount TeachesFig. 3. A more complex design, describing part of a universityThe problems arise when we consider a classical object-oriented implementation ofsuch a design. The student class, for example, starts with easy and obvious declarationsfor attributes (and signatures for methods) that provide the central functionality for eachclass. These are relatively simple, storing the key attributes and doing basic calculations.In Java, for example, the code may be as follows:class Student {String name;Integer number;HashSet attends; } The course class is similar — but at the bottom, we also find various pieces of code for explicitly representing and maintaining the relationships between these classes. class Course { String code; String title; int workload; HashSet attendees; HashSet prerequisites; HashMap