732 HOW TO FIND THE CLASSES $22.3 insight that sets the gifted designer apart.(That they are the most difficult to find does not mean they are the most difficult to build,a distinction that usually belongs to the implementation classes,unless of course you come across a ready-to-be-reused implementation library. External objects:finding the analysis classes Let us start with the analysis classes,modeled after external objects. We use software to obtain answers to certain questions about the world (as in a program that computes the solution to a specific problem),to interact with the world (as in a process control system),or to add things to the world(as in a text processing system). In every case,the software must be based on some model of the aspects of the world that are relevant to the application,such as laws of physics or biology in a scientific program, the syntax and semantics of a computer language in a compiler,salary scales in a payroll system,and income tax regulations in tax processing software. To talk about the world being modeled we should avoid the term "real world",which is See“Reality:a misleading,both because software is no less "real"than anything else and because many cousin twice of the non-software "worlds"of interest are artificial,as in the case of a mathematical removed".page 230. program dealing with equations and graphs.(An earlier chapter discussed this question in detail.)We should talk about the external world,as distinct from the internal world of the software that deals with it. Any software system is based on an operational model of some aspect of the external world.Operational because it is used to generate practical results and sometimes to feed these results back into the world;model because any useful system must follow from a certain interpretation of some world phenomena. Nowhere perhaps is this view of software as inescapable as in the area of simulation. See“SIMULA” It is no accident that the first object-oriented language,Simula 67,evolved from Simula 1, 35.1,page1113. a language for writing discrete-event simulations.Although Simula 67 itself is a general- purpose programming language,it retained the name of its predecessor and includes a set of powerful simulation primitives.Well into the nineteen-seventies,simulation remained the principal application area of object technology (as a look into the proceedings of the annual Association of Simula Users conferences suffices to show).This attraction of O-O ideas for simulation is easy to understand:to devise the structure of a software system simulating the behavior of a set of external objects,what could be better than using software components which directly represent those objects? In a broad sense,of course,all software is simulation.Capitalizing on this view of software as operational modeling,object-oriented software construction uses as its first abstractions some types deduced from analyzing the principal types ofobjects,in the non- software sense of the term,in the external world:sensors,devices,airplanes,employees, paychecks,tax returns,paragraphs,integrable functions. These examples,by the way,suggest only part of the picture.As Walden and Nerson note in their presentation of the B.O.N.method:732 HOW TO FIND THE CLASSES §22.3 insight that sets the gifted designer apart. (That they are the most difficult to find does not mean they are the most difficult to build, a distinction that usually belongs to the implementation classes, unless of course you come across a ready-to-be-reused implementation library.) External objects: finding the analysis classes Let us start with the analysis classes, modeled after external objects. We use software to obtain answers to certain questions about the world (as in a program that computes the solution to a specific problem), to interact with the world (as in a process control system), or to add things to the world (as in a text processing system). In every case, the software must be based on some model of the aspects of the world that are relevant to the application, such as laws of physics or biology in a scientific program, the syntax and semantics of a computer language in a compiler, salary scales in a payroll system, and income tax regulations in tax processing software. To talk about the world being modeled we should avoid the term “real world”, which is misleading, both because software is no less “real” than anything else and because many of the non-software “worlds” of interest are artificial, as in the case of a mathematical program dealing with equations and graphs. (An earlier chapter discussed this question in detail.) We should talk about the external world, as distinct from the internal world of the software that deals with it. Any software system is based on an operational model of some aspect of the external world. Operational because it is used to generate practical results and sometimes to feed these results back into the world; model because any useful system must follow from a certain interpretation of some world phenomena. Nowhere perhaps is this view of software as inescapable as in the area of simulation. It is no accident that the first object-oriented language, Simula 67, evolved from Simula 1, a language for writing discrete-event simulations. Although Simula 67 itself is a general￾purpose programming language, it retained the name of its predecessor and includes a set of powerful simulation primitives. Well into the nineteen-seventies, simulation remained the principal application area of object technology (as a look into the proceedings of the annual Association of Simula Users conferences suffices to show). This attraction of O-O ideas for simulation is easy to understand: to devise the structure of a software system simulating the behavior of a set of external objects, what could be better than using software components which directly represent those objects? In a broad sense, of course, all software is simulation. Capitalizing on this view of software as operational modeling, object-oriented software construction uses as its first abstractions some types deduced from analyzing the principal types of objects, in the non￾software sense of the term, in the external world: sensors, devices, airplanes, employees, paychecks, tax returns, paragraphs, integrable functions. These examples, by the way, suggest only part of the picture. As Waldén and Nerson note in their presentation of the B.O.N. method: See “Reality: a cousin twice removed”, page 230. See “SIMULA”, 35.1, page 1113