OBJECT-ORIENTED MODELLING OF COMMUNICATING GIS-BASED APPLICATIONS

合集下载

MBD Research Activities at

MBD Research Activities atVienna University of TechnologyMarkus Stumptner and Franz Wotawa11IntroductionOver the past10years the Database and Expert-system Group of theInstitut f¨u r Informationssysteme located at the TU Wien has doneresearch in many subﬁelds of AI,including Model-based Reason-ing(MBR).Within MBR algorithms for consistency-based diagno-sis[7,3],abductive diagnosis[4],and the integration of repair intothe diagnosis process[5,6,8]has been explored.In the last years research has focused on applying model-based di-agnosis to software debugging[1].This line of research was initiatedby the DDV project funded by Siemens Austria.Section2gives anoverview of the project and future research activities.Another direction of research includes the object-oriented designof diagnosis kernels,providing a language for deﬁning new diag-nosis components and complete diagnosis systems(see section3).Motivated by this work,our group has spent effort on building newmore efﬁcient diagnosis algorithms which can be used also for verylarge systems(up to10.000components and more).See[17]for analgorithm for tree-structured diagnosis systems.Currently we are involved in a project with the aim of buildingscale-able diagnosis agents running on workstations,PCs,and per-sonal digital assistants(PDAs),and are able to communicate diag-nosis informations to each other.Section4gives an overview of thisproject.2Automatic Software DebuggingThe basic principles of applying model-based diagnosis for softwaredebugging is shown inﬁgure1(a).The behavior of a program,givenby the semantics of the used language,is compared with the intendedbehavior which is given by an oracle,i.e.,the user or a(formal)spec-iﬁcation.In case of behavioral differences discrepancies occur whichare related to diagnosis candidates.In this context the piece of soft-ware can be viewed as system description and the oracle as physicalsystem,which is contrary to the traditional model-based diagnosisview.There the system description is assumed to be correct and thephysical system may contain a bug.Inﬁgure1(b)the practical realization is depicted.The systemdescription is composed out of a part,where the semantics of theprogramming language is modelled,and a part giving the structuralinformation,i.e.,used components and their interconnections,whichcan be automatically derived for every program using a compiler.From the speciﬁcation based test cases we obtain the observations,e.g.,variable values.The(logical)system description together withthe observations determine the diagnosis candidates.Since programparts,e.g.,expressions,statements,processes,procedures,...,aredirectly mapped to diagnosis components,the computed diagnosesmap back to the possible bug locations within the program.For a discussion about other(automatic)software debugging ap-proaches[2].The application of model-based reasoning for programdebugging and other intelligent debugging techniques is describedin[19].Since1995,Siemens Austria has been funding the DDV:'DesignDebugging of VHDL Speciﬁcation'project,aimed at improving thehardware design cycle.In hardware design the hardware description language VHDL[21]is used which is similar to Ada.VHDL pro-grams have a concurrent part consisting out of processes using sig-nals for communication.The behavior of processes has to be speci-ﬁed using sequential statements.VHDL programs are compiled and simulated,resulting in waveform traces,i.e.,signal changes over time.Waveform traces(seeﬁgure2for a typical trace)are com-pared with a speciﬁcation or another trace.In case of discrepancies the VHDL program contains a bug which has to be ﬁxed.Figure2.A typical waveform traceIn order to reach the project's aim two tools have been developed. These tools areﬁtted to the hardware designer's development envi-ronment,which consists out of a(vendor speciﬁc)compiler,simula-tor and a waveform trace viewer.The waveform compare tool(WF-COMP)automates the compare task and provides several different compare modes[16].WFCOMP results can be directly used for lo-cating the bug(s)using the debugging tool VHDLDIAG.Because of the program size(up to10MB source code and up to several days of simulation time for large designs)a very abstract model has been in-troduced for debugging[9,16]which is suitable for focusing on fault candidates even for large programs.The model based on the depen-dencies between signals and variables given by the program structure which is similar(but not identical)to program slicing([22,23]). Our group is currently working on improving the diagnosis capa-bility,although these methods are initially intended to be only used with small VHDL programs.In particular,we have examined ex-tensions of models for the description of VHDL programs based on modelling the correct behavior ofconcurrent signal assignments[15]the VHDL sequential part[14]the VHDL sequential statements considering semantical differ-ences between signal and variable assignments together with the temporal consequences and natural diagnoses ordering criteria.[20]Due to their rare occurrence in real-world VHDL designs,espe-cially for synthesise-able programs,which do not allow their use at all,these models do not handle loop constructs and recursive func-tions.The behavior model described in[20]has been implemented and is currently tested using examples from real-world VHDL design projects.Based on experiences from the DDV project,software diagnosis has been analysed on a more theoretical basis[13].Results from pre-vious research will be used in the project JADE'Java Diagnosis En-gine'.JADE is funded by the Austrian Science Fund(FWF)and has the aim of extending a Java debugger with automatic faultﬁnding and repairing capability.JADE will begin in June1998.One objective is to experiment with extensions to the proposed debugging approach to handle recursive functions,global variables,and other advanced constructs.3Diagnosis EnginesThe objective of project DIKE('Diagnosis Kernel'),a project funded by Siemens Austria,was to provide an object-oriented diagno-sis framework.Generality,extensibility and providing methods for easy building and updating of diagnosis systems were the main re-quirements.The framework was implemented using ObjectShare Smalltalk Visualworks2.52.Within DIKE,diagnosis systems with hierarchical components and several behavioral modes can be described.Probabilities for all modes,repair costs and informations and observation costs can be speciﬁed.It has also been shown that the provided language,used for writing behavior descriptions and diagnosis systems,can be used in a wide range of application domains.A number of example models were developed as part of the project.These include simple models fordigital and analog circuits,reconﬁguration of telecommunication systems[18],sound-switching systems used in radio and television broadcast-ing[12],a domain already examined previously in the context of other methodsThe diagnosis engine,based on[11],has the capability of search-ing faults in a breadth-ﬁrst order,depending on the number of com-ponents invoked or depending on the probability of a diagnosis.The maximum number of diagnoses and the maximum diagnosis size can be speciﬁed as parameters.In addition,the automatic generation of a fault mode and effect analysis(FMEA)is supported within the im-plemented framework.4Mobile Diagnosis AgentsThe MODIS:'Mobile Diagnosis'project funded by the Hochschulju-bil¨a umsstiftung der Stadt Wien has the aim to build diagnosis agents with communication capability and which run on multiple platforms such as workstations,PCs,and PDAs.Currently,a language for de-scribing the behavior and the structure of diagnosis systems is in de-velopment.This language will offer constructs for describing differ-ent behavioral modes,their probabilities,repair actions and repair costs,observation costs,physical impossibility axioms,among oth-ers.The description of hierarchical systems is also possible.The full syntax and semantics of the language together with a parser written in Smalltalk will be made available at the end of this year.Other objectives of MODIS are:Deﬁning an object-oriented framework for communication be-tween multiple diagnosis and interface agents.In this part of the project,a communication language is used to transfer system de-scriptions,observations,results,and other diagnostic information.The framework itself must beﬂexible enough to provide commu-nication via several channels,e.g.,via email,remoteﬁle access, and socket-based communications.Improving diagnosis algorithms to be usable in PDAs for medium size diagnosis systems(components).Since PDAs have restricted memory and computational power,algorithms must be optimised in order to reach the goal of providing a mobile diag-nosis assistant with appealing user-interaction.Currently there are several algorithms available which can be used.Some are general(e.g.,[10])and others are restricted to systems satisfying certainstructural properties(e.g.,[17]).Deﬁning a framework for the graphical user interface of diagno-sis systems.Different resolution sizes(from320240black-and-white up to1024800with16Mio Colours)and input devices (mouse,keyboard,touch-screen)must be supported.Figure3gives an overview of the MODIS objectives.Internet EMail, Sockets, Remote File Access,er-Interface FrameworkMultiple Communication Channels Communication LanguageDiagnosis Language Diagnosis Agent FrameworkPDAs NotebooksPCs Multiple Platforms MODISFigure 3.The MODIS project 5Outlook on Future ActivitiesMore recent projects include studies on the topic of monitoring tech-nical systems,e.g.,in facility management.Work in this area requires more sophisticated representation of temporal aspects.AcknowledgementThis work has been supported in part by research grant DDV GR 21/96106/4from Siemens Austria,by grant H-00031/97from the Hochschuljubil¨a umsstiftung der Stadt Wien,and by the Christian Doppler Laboratory for Expert Systems.REFERENCES [1]Luca Console,Gerhard Friedrich,and Daniele Theseider Dupr´e ,`Model-based diagnosis meets error diagnosis in logic programs',in Proc.IJCAI ,pp.1494–1499,Chambery,(August 1993).Morgan Kaufmann Publishers,Inc.[2]Mireille Ducass´e ,`A pragmatic survey of automatic debug-ging',in Proceedings of the 1st International Workshop on Automated and Algorithmic Debugging,AADEBUG '93,Springer LNCS 749,pp.1–15,(May 1993).[3]Hartmut Freitag and Gerhard Friedrich,`Focusing on indepen-dent diagnosis problems',in Proc.KR '92,Cambridge,MA,(October 1992).[4]Gerhard Friedrich,Georg Gottlob,and Wolfgang Nejdl,`Hy-pothesis classiﬁcation,abductive diagnosis and therapy',in Proceedings of the International Workshop on Expert Systems in Engineering ,Vienna,(September 1990).Springer Verlag,Lecture Notes in Artiﬁcial Intelligence,V o.462.[5]Gerhard Friedrich,Georg Gottlob,and Wolfgang Nejdl,`To-wards a theory of the repair process',in Proceedings of the Portuguese Conference on Artiﬁcial Intelligence ,Albufeira,(October 1991).Springer AI Lecture Notes.Also appeared at the Model-Based Reasoning Workshop,AAAI'91,July 1991,Anaheim.[6]Gerhard Friedrich,Georg Gottlob,and Wolfgang Nejdl,`For-malizing the repair process',in Proc.ECAI ,Vienna,(August 1992).Appeared in Second International Workshop on Princi-ples of Diagnosis,Milano September 1991.[7]Gerhard Friedrich and Wolfgang Nejdl,`MOMO —Model-based diagnosis for everybody',in Proceedings of the IEEE Conference on Artiﬁcial Intelligence Applications (CAIA),Santa Barbara,(March 1990).A slightly revised and extendedversion appears in Readings in Model-Based Diagnosis (Mor-gan Kaufmann,1992).[8]Gerhard Friedrich and Wolfgang Nejdl,`Choosing observa-tions and actions in model-based diagnosis-repair systems',in Proceedings of the International Conference on Principles of Knowledge Representation and Reasoning ,pp.489–498,Cam-bridge,MA,(October 1992).Morgan Kaufmann Publishers,Inc.[9]Gerhard Friedrich,Markus Stumptner,and Franz Wotawa,`Model-based diagnosis of hardware designs',in Proc.ECAI ,Budapest,(August 1996).[10]Peter Fr¨o hlich and Wolfgang Nejdl,`A Static Model-Based Engine for Model-Based Reasoning',in Proc.IJCAI ,Nagoya,Japan,(August 1997).[11]Raymond Reiter,`A theory of diagnosis from ﬁrst principles',Artiﬁcial Intelligence ,32(1),57–95,(1987).[12]Johannes Retti,Wolfgang Nejdl,and Gerhard Friedrich,`AR-TEX —Knowledge based fault detection and correction in a switching system',in Proceedings of the International GI Conference on Knowledge Based Systems ,M¨u nchen,(1987).Springer-Verlag.[13]Markus Stumptner and Franz Wotawa,`A model-based ap-proach to software debugging',in Proceedings on the Seventh International Workshop on Principles of Diagnosis ,Val Morin,Canada,(1996).[14]Markus Stumptner and Franz Wotawa,`Model-based diagno-sis of hardware description languages',in putational Engineering in Systems Applications CESA'96IMACS Mul-ticonference,Invited Session on Model-Based Systems ,Lille,(1996).[15]Markus Stumptner and Franz Wotawa,`Model-based program debugging and repair',in Proceedings of the International Conference on Industrial and Engineering Applications of Ar-tiﬁcial Intelligence and Expert Systems ,Fukuoka,(1996).[16]Markus Stumptner and Franz Wotawa,`A model-based tool for ﬁnding faults in hardware designs',in Proceedings Artiﬁcial Intelligence in Design ,Stanford,(1996).[17]Markus Stumptner and Franz Wotawa,`Diagnosing tree-structured systems',in Proceedings International Joint Conf.on Artiﬁcial Intelligence ,Nagoya,Japan,(1997).[18]Markus Stumptner and Franz Wotawa,`Model-based reconﬁg-uration',in Proceedings Artiﬁcial Intelligence in Design ,Lis-bon,Portugal,(1998).To appear.[19]Markus Stumptner and Franz Wotawa,`A Survey of Intelligent Debugging',AI Communications ,11(1),(1998).To appear.[20]Markus Stumptner and Franz Wotawa,`VHDLDIAG+:Value-level Diagnosis of VHDL Programs',in Proceedings on the Ninth International Workshop on Principles of Diagnosis ,Cape Cod,(May 1998).[21]IEEE Standard VHDL Language Reference Manual LRM Std 1076-1987,1988.[22]Mark Weiser,`Programmers use slices when debugging',Com-munications of the ACM ,25(7),446–452,(July 1982).[23]Mark Weiser,`Program slicing',IEEE Transactions on Soft-ware Engineering ,10(4),352–357,(July 1984).。

Modelica语言介绍

end Controler;
der(y) = 0; y = -(b/a)*u;
22
受限类（Restricted Classes）
class： model connector record block type function package
用途：更精确地表达模型含义增强易用性和可读性便于编译器作限制性检查可以改成class而不影响模型行为
24
受限类Model
不能用于连接。
model Pendulum …
end Pendulum;
25
受限类Connector
类定义及其任何组件中不允许有方程。
connector Pin
Voltage
v;
flow Current i;
end Pin;
26
受限类Record
只有公有（public）变量。不能用于连接（connection）。记录不能直接用来仿真。成员变量不能声明为input/output、inner/outer、flow。
23
受限类使用场景
类型 class model connector record block type function package
名称类模型连接器记录框图类型函数包
作用通用类陈述式模型组件之间的连接接口数据结构兼容基于框图的因果建模类型别名通过算法实现过程式建模消除名字冲突和组织模型层次
6
例子：HelloWorld
Modelica模型组成：声明（变量、参数）方程（equation）
class HelloWorld Real x(start=1); parameter Real a=1;

Coad's Object-Oriented Analysis

VII. Implementation & Evaluation On-going Maintenance Phase
OOAD only affects phase III, IV, and V. The other phases remain the same.
© 1995 John Mylopoulos
© 1995 John Mylopoulos
Object-Oriented Analysis -- 9
s
s
Phase V: Develop and Document
s
s
s s s
The system is implemented on the basis of the design specification. Analyst works with programmers to develop any original software needed Analyst uses structured techniques (pseudo code, flowcharts,…) to communicate with the programmers Programming of the system is carried out Program testing is carried out Procedures, system manuals, software specifications and documentation are completed
Object-Oriented Analysis -- 14
Five Layers to OOA
s s s s s
Class/Object Layer Structure Layer Service Layer Attribute Layer Subject Layer

Abstract Object-Oriented Development of a Data Flow Visual Language System

2.4 PHF execution protocol
A PHF program is executed from its outermost vip. The execution mode implemented by PHF is, as with most current data flow visual languages, data driven (all vips which have inpu .
The syntax of PHF-like that of many other data flow visual languages-consists of boxes and arrows, a box representing a process, and an arrow representing a data flow between processes. Boxes are called vips (visually interactive processes) in PHF, and arrows are called connectors. Computation in PHF is carried out by a homogenous community of vips communicating with each other. Vips can be recursively nested. The vip is the only unit of system decomposition in PHF, paralleling the design of LISP, in which lists are
ProtoHyperflow (PHF) is a data flow visual programming language which is a derivative subset of Hyperflow. While Hyperflow is designed as a visual language for a pen-based multimedia system, PHF is implemented on a traditional, mouse/CRT-based system using C++ and the user interface application framework ET++ [12, 3, 13, 11. PHF is a general purpose visual language system consisting of an integrated editor and a data driven interpreter system. The following is an informal description of the PHF language. Most of the language constructs available in PHF appear in other data flow visual languages, thus forming the basis for factoring out commonalities into an application framework.

Extending an Object-Oriented Model to Support Coordination.

Extending an Object−Oriented Model toSupport Coordination.Emmanuel LENORMAND, Roland BALTERUnite Mixte Bull−IMAGCentre Equation2 Avenue de Vignate38 610 GIERESFRANCEe−mail: [Emmanuel.Lenormand, Roland.Balter]@imag.frAbstract:The Guide distributed object−oriented platform provides an integrated environ-ment for building distributed applications based on the object paradigm. It is in-tended to extend this model as well as the functionalities of the run−time systemto provide better support of groupware applications involving the coordination ofcooperating activities. This paper describes the extensions to the basic ob-ject−oriented model required to achieve this objective.1Background: The Guide Object−Oriented Model.The Guide platform provides an integrated environment for the development and execu-tion of distributed applications handling persistent data. This environment allows distributed applications to be developed using a high−level object oriented language. The Guide platform comprises a run−time system, a number of applications services, built as objects, and a set of development tools, including the compiler of the language, a distributed debugger and a class browser. Two versions of the platform are available: one is running as a software layer on top of Unix; another version is implemented directly on top of the Mach 3.0 micro−kernel and provides full interoperability with the OSF−1 server.In Guide, applications are structured in terms of objects. Objects are fine−grained passive entities which are stored in a multi−site location transparent secondary storage. They are loaded on demand into a virtual memory for execution.The main execution unit used by applications is the job, which may be viewed as a mul-tiprocess virtual machine composed of distributed concurrent activities operating on objects.A basic operation in the system is object invocation. An invocation specifies the system reference of the invoked object, the name of a method and the parameters of the invocation. The reference contains a unique object identifier, called Oid, and location hints. Since the2Extending an Object−Oriented Model to Support Coordination.objects may be located on different nodes, jobs and activities may be distributed. However, the distribution is hidden from the user. At the application level, communication between jobs and activities entirely relies on object sharing. Object sharing is controlled through the use of a set of synchronization constraints, expressed in terms of guards associated with methods, which are specified in the class of the object.The Unix version of the Guide platform was intensively used for the construction of pilot cooperative applications. This included a cooperative structured document editor, a workflow application dealing with the circulation of documents and folders within an en-terprise and a multi−user distributed spreadsheet. Complementary experience was also gained from the implementation of the development environment itself, built in terms of objects. It includes a coordination service, which allows the cooperation of interdependent development tools, such as the browser, the syntactic editor, the compiler, and the debug-ger[Boyer94]. From these early experiments, it was possible to evaluate the benefits and weaknesses of the Guide approach for the expression and control of coordination. This analysis leads us to revise the Guide computational model to better fit cooperative applica-tion requirements.This study is currently in progress and we describe its guiding principles in Section 2.2Specific Requirements for Coordination.The way we understand coordination remains close to the definition given in [Malone90]:[Coordination is] the act of managing interdependencies between activities performed to achieve a goal.Our objective is not to define a coordination model but to provide a set of abstractions and tools which will allow the construction of a large variety of coordination models. Based on the current definition of the Guide model and system, the main issues to be addressed are: the ability to manage activities (section 2.1), integration of pattern−based and name−based com-munications within the name service (section 2.2) and additional communication and syn-chronization facilities based on event handling (section 2.3). Finally, section 2.4 introduces the concept of event broker which aims at combining the functionalities of the naming ser-vice and the event−based communication service. It is expected that the event broker would greatly assist application programmers in the design of coordination services.2.1Activity management.From Malone’s definition, it appears that activities (i.e. active entities) are central to the design of coordination capabilities. Thus there is a need for the actual management of activities. This includes creating, deleting, suspending, resuming a given activity, or a group3 of activities, as well as the ability for a given activity to react to external events according todefined behaviours.At the time being, activities defined in the Guide model are part of the computational model, but they are not part of the application programming interface. Consequently there is a need to make activities actually visible from the application designer.Two approaches are currently considered for activity handling. The first approach con-sists in considering activities as first−class objects and to treat them as standard objects (at least from the programmer point of view). In this approach a type "Activity" is defined which specifies a basic behaviour for an activity as well as state variables (activity variables do not exist at the time being in Guide). Behaviour definition includes not only the methods which can be applied on the activity object but also a set of event handlers for the treatment of incoming events. A given behavior may then be refined using the inheritance mechanism. However, it is anticipated that complete freedom in the definition of new behaviors may lead to severe implementation problems. Moreover, the uniformity of definition and manipulation for passive and active entities (objects and activities) may be confusing for the program-mer.An alternative approach consists in considering activities as a new category of entities besides existing ones, namely types, classes and objects. Since the nature of activity may change from one application domain to another, it would be necessary to define different basic classes of activity with their own behavior. This solution would certainly allow better control and easier implementation. At the opposite, this solution has one major drawback, insofar as it introduces a new concept at the model level, which may become quite cum-bersome. In case this approach prevails, the aims of each type of entities (active or passive) would have to be clearly separated, or the programmer could use either one or the other to reach the same goal, thus lead to a confused style of programming.A third approach would consist in considering the use of active objects, that is objects which hold their own thread of control. This was rejected because objects in Guide are usually small and the cost of implementing a large number of small active objects is pro-hibitive. Moreover, this approach could lead to the confused and mixed style of programming we condemned above.2.2Advanced naming service.Since activities are now handled at the programming level, they must be identified. The question is raised to know whether the current naming facilities are satisfactory or if they should be extended.In Guide, the communication between objects is name−based (i.e. objects are identified by their name). Object naming takes two forms which correspond to two levels of naming. At the lowest level objects are accessed through typed references which hold a unique sys-tem−wide object identifier (Oid). However objects may also have one or more symbolic names which are handled by a naming service. In its current implementation symbolic names are4Extending an Object−Oriented Model to Support Coordination.organised according to a hierarchical structure using directories. A simple name service allows the retrieval of an object identifier given its symbolic name.Name−based communication is rather insufficient for the support of certain forms of co-ordination where the identity of the cooperating activities involved in a partnership is not necessarily known. A typical example is a distributed cooperative document editor where the actual modifications carried out on a part of the document should be propagated only to those companion authors "who are interested in" this part of the document. That is why coordi-nation also requires pattern−based communication, where the identity of cooperating activities is defined by a set of properties. Properties may include type or class information, as well as public attribute or state data.2.3Communication and synchronization.Coordination combines two basic aspects: communication and synchronization. One can distinguish two kinds of interaction between agents whether the communication between them is performed directly, using events, or indirectly through shared objects.As mentioned in Section 1, the Guide model provides object sharing and the ability to specify sophisticated synchronization schemes. On the contrary, direct communication be-tween agents is not supplied; the lack of an event mechanism was already raised by experi-ments with Guide[Boyer94] and is stressed by the new orientation we are taking.An event mechanism allows activities to react to changes in the state of the system by sending particular messages which entail reactions by their addressees[Menon93].The basic principles of the event−based communication are as follows:•events are raised by activities. They can be viewed as messages which are typed and contain context data. Events are conveyed to recipient activities in two ways.They may be directly addressed to a set of selected activities or they may be addressed to an event−broker (see 2.4) which forward them to those activities which have "shown interest" in these events.•on the receiving side, the reception is allowed by the execution of a handler. These activations are dynamic, and so are the deactivations. Thus, the set of events in which an entity is interested evolves at will. Each handler is part of the interface of the activity and its execution is performed within the addressee. The definition of handlers remains crucial − should they only be defined within activities or may they also be defined within classes the activities execute? − as the problem of their (de)activation.The synchronization associated with these mechanisms indicates on which conditions an event is raised by an agent −blocking or non−blocking−, notified to an agent −queued or handled at once− or handled by an agent −handled concurrently or sequentially. Thus, this mechanism allows multiple synchronization schemes to be described, depending on the combination of properties of raise, notification and treatment of events.52.4Event Broker.In 2.3, we have introduced the notion of an event broker to perform event switching be-tween senders and receivers. The event broker integrates within a single component two functions: naming and event management.Its role comprises two functions. First, it has to manage the relationships between activities and events. From the sender point of view, it registers what activity may send what type of event. From the receiver point of view, it maintains an updated list of activities and their associated handlers. It may also register the status of each handler (activated vs de-activated). In addition, it implements the actual switching of event according to various policies as described in the OMG recommendation[OMG93].3Conclusion.We list above the extensions that may be relevant to support coordination in an extended object−oriented model. Our aim is now to integrate these features to the existing Guide language and run−time system to provide programmers with powerful tools to design coop-erative applications.This integration implies the introduction at the language level of new constructs for defining, manipulating and designating activities and events. Then, the associative naming facilities entail deep modifications in both language and run−time system. The language must propose constructs which enables such a naming, without overriding classical "per Oid" naming. The run−time system must provide support for a naming service which takes in ac-count the passivity of objects and dynamicity of activities to give a uniform naming scheme. This service can be partly inspired by X500 services. Finally, the run−time system will evolve to supply an event mechanism and a support for integrating it with the naming service in the event broker.Bibliography[Boyer94] Boyer F., Coordination entre outils dans un environnement de développement de logiciels, Thèse de Doctorat de 3ème cycle, Université Joseph Fourier, Grenoble, France, February 1994.[Malone90] Malone T.W. et Crowston K., ‘‘What is Coordination Theory and How Can It Help Design Cooperative Work Systems’’, CSCW’90: Proceedings of the Conference on Computer−Supported Cooperative Work, édité par F. Halasz, pp. 357−370, Asso-ciation for Computing Machinery, October 1990.[Menon93] Menon S., Dasgupta P. et Leblanc R.J., ‘‘Asynchronous Event Handling in Dis-tributed Object−Based Systems’’, ICDCS’93, pp. 383−390, May 1993.[OMG93] Object Management Group, Joint Object Services Submissions: Ch.1 Event Ser-vice Specification, (93.2.3), February 1993.。

What is the “Object” in Object-oriented Programming 1

What is the“Object”in Object-oriented Programming?1O.M.NierstraszAbstractObject-oriented programming has become quite widespread in recent years,although there arefew guidelines to help us distinguish when a system is“truly”object-oriented or not.In thispaper we discuss what have emerged as the main concepts in the object-oriented approach,andwe attempt to motivate these concepts in terms of how they aid in software development.R´e sum´eBien que la programmation-objet soit devenue assez courante ces derni`e res ann´e es,il n’existeque peu de r`e gles qui nous permettent de savoir si un syst`e me est v´e ritablement orient´e objetou pas.Le pr´e sent article expose les concepts principaux associ´e s`a l’approche orient´e e objet,qu’il tente de justiﬁer en mettant en exergue leur rˆo le dans le d´e veloppement d’applicationslogicielles.1IntroductionThere is much confusion about the term“object-oriented”,which it appears can be applied to anything from an operating system to an interface for a text editor.Although there are a number of things the term normally brings to mind,there is no clear way of telling whether system A is “really”object-oriented,and system B is not.In this paper we will discuss a number of object-oriented“concepts”,and put forward the hypothesis that object-orientation is an approach rather than a speciﬁc set of language constructs. In fact,one can probably use an arbitrary programming language and still write in an object-oriented style.However,object-oriented programming languages do exist with built-in constructs that support(or enforce)this style of programming.The principle that is fundamental to the object-oriented approach is encapsulation,or more precisely,data abstraction:an“object”packages an entity(data)and the operations that apply to it.In its most basic form we may have a module of a program consisting of a number of static variables together with the set of procedures that are used to manipulate the variables.In general, those variables are“private”:the object is deﬁned by its behaviour,not its representation.So if I have an object called“Jaguar”,I do not change its colour by modifying its“colour”variable,but by executing an operation such as“paint”.The notion of data abstraction is especially useful if one can apply it to multiple instances of an object“type”.A language like Fortran provides aﬁxed set of data types,such as integers and real numbers,each of which supports a number of operations(addition,subtraction...).Languages like C and Pascal support the construction of programmer-deﬁned types,one cannot deﬁne new type-speciﬁc operations.Object-oriented languages enable the programmer to create his(or her) own object types.Each object is then an instance of some type,and supports the operations(called 1In Proceedings of the CERN School of Computing,CERN87-04,pp.43-53,Renesse,The Netherlands,Aug. 31-Sept.13,1986.2What is the“Object”in Object-oriented Programming? methods)that are deﬁned for that type.(The word“class”is often used interchangeably with the word“type”when talking about objects,however,it is more precise to think of an object class as the set of instances of an object type.)Object“independence”is the notion that each object is ultimately responsible for itself.Objects can only be manipulated via their methods.Supporting this idea of object independence is a model for object communication which replaces the notion of operating on objects with that of passing messages to them.Every method invocation is seen as a message requesting the object to perform some action.The method is(conceptually) not performed by the caller,but by the object receiving the message.It follows,then,that the recipient of such a message is,in some sense,free to refuse the request,or choose from a variety of possible implementations of the method.Classes of objects may not be disjoint.Object types may form a hierarchy in which a subtype “inherits”the methods of one or more parent types.The implementation of the subtype’s methods may or may not be inherited from the parent.In fact,one may even have multiple implementations of a single type which only share their interface.By properly organizing such a type hierarchy,one may concentrate on the similarities between objects rather than on their diﬀerences.Fully object-oriented systems have a strong degree of homogeneity.This means that everything is an object.One does not distinguish between,say,programs and processes andﬁles and objects –one only has objects,and objects are both active(like processes)and persistent(likeﬁles).In particular,the object types(or,more precisely,the type speciﬁcations)are objects of the type called“type”.A natural step to take is to map objects to an“actor”model of computation.Simply put, an actor is a cheap,persistent,message-passing process.(The actor formalism as described in [11]is more rigorous,however this simple deﬁnition suﬃces for our purposes.)An actor must be inexpensive because we would like to be able to easily create and destroy them.If there is a one-to-one mapping between actors and objects,then it is clear that we may have many more actors than there are processes in a traditional multiprocessing environment,though at any one time only a few actors will actually be doing anything.The message-passing paradigm supports the notion of actors communicating with one another whether they are running on the same machine or not. If we consider objects to be active entities running“on top of”actors,then we see that the object-oriented approach also provides us with an easy way to understand concurrency,and applications running on a network of machines.At the same time,we note that there are several object-oriented languages and environments that do not support the notion of concurrently executing objects.The main object-oriented concepts,then,are:1.Data abstraction.2.Independence.3.Message-passing paradigm.4.Inheritance.5.Homogeneity.6.Concurrency(some systems).O.M.Nierstrasz3 We shall elaborate on each of these concepts in turn,and attempt to explain their importance. 2Data abstraction.By far the most important concept in the object-oriented approach is data abstraction.By this we mean that we are interested in the behaviour of an object rather than in its representation.Every object has a clearly deﬁned interface which is independent of the object’s internal representation. The interface is a collection of operations,or“methods”,which may be invoked by another object.Furthermore,one may have many instances of an object type.The programmer is not restricted to aﬁxed set of types,but is free to add new types as required.This capabilityﬁrst appeared in the programming language“Simula”[3],a simulation language in which the programmer was able to deﬁne his own“classes”of objects(i.e.,corresponding to the real objects one wished to model).A type deﬁnition looks very much like a module:there are a collection of permanent variables that encode the“state”of the object,and a set of methods that use and change that state.A module,however,only deﬁnes a single instance,whereas one may have many instances of a new type.In order to make use of an instance of that type,one only needs to know what the interface is, namely,the names of the methods,and the types of the input and output parameters.(Naturally some speciﬁcation of the semantics of the methods is also required.)The most immediate beneﬁt of this approach is that the programmer is free to use higher levels of abstraction as appropriate.(I.e.,at each level of abstraction one concentrates on that level’s functionality,while hiding the lower-level details of implementation.)One is encouraged to decompose a programming problem into a collection of cooperating objects of varying levels of complexity.The separation of interface and implementation of a new type means that types are,to some extent,representation-independent.This makes it easier to experiment with diﬀerent implementa-tions of an object type,and increases the portability of software.It is,however,crucial to design an interface very carefully,since that is the part of an object type that remains stable across diﬀerent implementations.A language that allows programmers to deﬁne their own types is a natural candidate for strong typing.Type-checking is done as soon as possible,usually at compile-time.(Sometimes one does not know at compile-time what kinds of objects will be manipulated,so one must do explicit type-checking at run-time;for example,a mailbox object may hold various types of mail objects.) In an object-oriented language,one is typically allowed to use the same method names for a variety of diﬀerent object types.This is called“overloading”,or polymorphism.For example,one may wish to deﬁne addition for complex numbers,and use the symbol“+”as the method name, even though it is already deﬁned for integers.The type of the object to which such a method applies is,in a sense,an implicit argument to the method.Without overloading,one would be forced to deﬁne the methods“complex add”,“integer add”,and so on.Overloading allows for more readable code.If used in an undisciplined fashion,however,overloading can have quite the opposite eﬀect.(As a grotesque example,consider the use of the symbol“+”as the method name for complex subtraction.)Well-designed objects are typically applicable in a number of situations.One can therefore expect in an object-oriented environment that most of the object types one deﬁnes can be re-used,4What is the“Object”in Object-oriented Programming? or,conversely,that when putting together an application,one canﬁnd many of the parts one needs already available as pre-deﬁned object types.3Independence.There are several notions of independence displayed by objects.The most fundamental is that objects have control over their own state.An object’s methods are the only interface to its state. Since this is not always guaranteed in languages that enable programmers to add new data types, it is worth emphasizing.Clearly,if one has access to the internal representation of an object,then one loses the property that the implementation is independent of the interface.Objects also have control over their own existence.Once created,an object will continue to exist(or persist)even if its creator dies.Persistent objects eliminate the need for“ﬁles”.One need not be concerned as a programmer with the location of an object in main memory or secondary memory.Ideally,dormant objects automatically“migrate”to passive memory.Garbage collection, however,is compatible with this notion,since an object that is neither active nor accessible is eﬀectively dead already.Another form of independence is the ability to add new object types at run-time.This is crucial if the object-oriented environment is also the development environment.Otherwise the addition of new types must take place“outside”.If new types are to be added dynamically,then old objects must be capable to talking to instances of the newly-created types.(Compile-time type-checking is clearly not possible for those objects that will talk to objects of types that do not exist yet.)4Message-passing paradigm.Independence of objects is supported conceptually by using message-passing as a model for object communication.In terms of the model it is clear that an object cannot“operate on”another object. The only way an object can interact with the outside world is by sending messages.Consequently, object A“invokes”a method of object B by sending B the message,“please execute this method”.Assuming all goes well and the message can actually be delivered,B is free to interpret the message as it pleases.It may choose amongst several ways of handling the request,it may delay responding,or it may decide that it does not wish to handle the request at all,and return an exception report.“Returning”is also accomplished by message-passing.It is important to realize that message-passing is a model for object communication rather than an implementation requirement.In fact,more than one object-oriented language translates message-passing into straightforward procedure calls.This is possible whenﬂow-of-control is single-thread,and no more than one object is“executing”at any time.However,in a concurrent environ-ment where objects are truly active,“real”message-passing is a natural way in which to implement communication between objects.Message-passing may be synchronous or asynchronous.Basically,the diﬀerence is that with asynchronous message-passing the message is put on a queue,and the sender is immediately free to concentrate on another task(though it usually just waits for a response).With synchronous message-passing,the sender blocks until the message can be delivered,sometimes even until theO.M.Nierstrasz5 recipient prepares a response.The problem with asynchronous message-passing is that it is(strictly speaking)impossible to implement,since there is no bound on the size of the message queues. The problem with synchronous message-passing is that it says nothing about the order of arrival of messages when multiple senders compete for a single recipient,and it limits the amount of concurrency by blocking the sender.Aynchronous message-passing is perhaps more consistent with the idea of object independence, but it is not a pre-requisite for an object-oriented system.5Inheritance.From the point of view of organizing software and reusability of code,the most important mecha-nism in an object-oriented language is the ability to specialize object types.A specialized type(a subtype)inherits the properties of its parent type,then possibly adds more properties.A program source,for example,may be seen as a specialization,(or reﬁnement)of a text object.An instance of a subtype responds to all the messages that the parent type understands. The reverse is not true.A subtype inherits the method interfaces of the parent type,but may add new methods that the parent cannot respond to.In addition,a subtype usually inherits the implementation of the parent by default,that is the set of instance variables that encode the state of a parent instance,and the implementations of all of the methods.The subtype could add new instance variables and methods.A subtype may,however,have a diﬀerent set of instance variables,and quite diﬀerent imple-mentations of the inherited methods.For example,real numbers are a reﬁnement of integers,but they are represented and implemented quite diﬀerently in a computer.The set of all object types forms a specialization hierarchy with the type object at the root. With simple inheritance,this hierarchy is a tree.If multiple inheritance is supported,the hierarchy is,in general,a directed acyclic graph.This means that a subtype may have more than one parent type(but no type can be its own ancestor!). The parent types in this case are called“traits”[7]or“ﬂavours”or“mixins”.The diﬀerence between a trait and a type(if any)is that a trait speciﬁes an interface,but it need not deﬁne an implementation.One reason for this is that a trait may not be of interest as a type on its own.Consider for example the trait“ownership”.Such a trait might specify methods for setting the owner of the object,changing ownership,and determining access rights.Ownership is only of interest in conjunction with other properties.An“owned object”would be of little use on its own.Multiple inheritance increases the reusability of software.Simple inheritance is inadequate for describing many of the useful relationships between object types.Suppose that we would like to have both owned and unowned pieces of text.Similarly we might have owned and unowned graphical objects.(An unowned object might be part of a larger owned object.)The type owned text is a reﬁnement of text,and owned graphic is a reﬁnement of graphic,but with simple inheritance there is no way to say that the methods pertaining to ownership are to be shared.Multiple inheritance encourages the programmer to deﬁne traits that can be combined much moreﬂexibly.The addedﬂexibility is not without its cost–there are no easy solutions if one wishes to combine6What is the“Object”in Object-oriented Programming? two traits that use the same method name to mean diﬀerent things.Provided there are no naming conﬂicts,multiple inheritance is an elegant mechanism for aiding in the design of new object types.Variation of types is another form of inheritance.A new type may be deﬁned as being equivalent to an existing type,adding no new methods.The type deﬁnition serves mainly to ensure correct use of objects of that type–type clashes can be detected by the compiler,or at run-time.One would not wish to confuse names of people with names of programs,even though they would both be implemented as strings.Furthermore,equivalent types may have implementations tailored to a particular environment or usage.Window objects may behave the same on a variety of graphic devices,yet will be implemented in diﬀerent ways.Similarly one might choose from a variety of implementations of lookup tables with diﬀerent overhead and performance characteristics,though all are functionally equivalent.A weak form of“inheritance”is parameterization.A“container”object is an object that manages objects of a given type(or set of types),yet is not concerned with what that type is. When an instance of a container is deﬁned(or created),the type of the contained object should be known.In the deﬁnition of the container type,the type of the contained objects is speciﬁed as a parameter.For example,one would deﬁne an array as an array of a contained type.When declaring an array,one would specify an array of integers,or an array of mail messages.(The array object does not care what it manages,but at some point the compiler needs to know what it will be.)6Homogeneity.In a“fully”object-oriented environment,“everything”is an object.One does not distinguish between programs and objects–objects are the active entities.Object types(or rather the speci-ﬁcations and implementations of object types)are objects too(of type type).This is necessary in a complete environment,since a programmer will need to instantiate new types from within the environment.To say that“everything”is an object is formally attractive,but one must take care.For example,are messages objects?If so,in order to manipulate a message,is it necessary to send it a message?This sort of circularity is normally broken at some level.It is fundamental to the object-oriented model that messages can be sent between objects,without having to deﬁne“how”this is done.More important is the ability to think of instance variables as objects.This enables a pro-grammer to construct complex objects whose parts are also objects.Again,the circularity most be broken at some point.Is it really useful to talk about the“parts”of an integer as objects?What are the instance variables of a single bit?In any case,it is the behaviour of objects that is crucial, not their representation.We should,therefore,not feel uncomfortable with the idea that certain basic object types are given,and all other types are built up from them.There is no need for us to know how the basic types are implemented.The principle of homogeneity can be carried even to the level of code.In Smalltalk,control structures are implemented using objects.A block expression is an object that can be executed by sending it the message value.Conditional execution is accomplished by sending an object of typeO.M.Nierstrasz7 boolean two block expressions,one to be evaluated if the value of the boolean is true,the other if it is false.Similarly,iteration is accomplished by sending an integer the message timesRepeat:,with a block expression to be executed as an argument.Carrying the notion of homogeneity to this degree certainly makes for a very consistent view of the environment,and it means that interpreted(rather than compiled)code can be understood in terms of communicating objects,but it also means that programmers may have to change the way they think about problem-solving at even very low levels.Does it help a programmer to think of the expression:1+2as“send the message‘+2’to the object1”?Probably not.At the same time it is reassuring that the object-oriented approach is suﬃciently powerful to capture computation at whatever level of abstraction.7Concurrency.The message-passing paradigm of object communication lends itself well to an environment in which every object is an active entity,i.e.,a process.Since there are large numbers of objects,one must be able to have large numbers of processes(most of which are normally“asleep”).Furthermore, since objects are persistent,it is desirable that the processes that implement them be persistent too.We call such processes actors,after the computational model invented by Hewitt[11].The actor formalism can be useful for understanding object interactions.From a purely practical point of view it is attractive to think of objects being implemented“on top of”actors.Actors,then,are inexpensive,persistent,message-passing processes.Objects add structure to the state of an actor, and provide structure to the message-passing that may take place.(For examples of actors as they appear in a programming language or an operating system,see[4]or[15].)Message-passing can be deﬁned in several ways.We have already discussed synchronous and asynchronous message-passing.In addition,an actor may be able to receive messages at a number of diﬀerent ports.Ports typically have diﬀerent priorities,so that messages sent to a port of high priority will be received before those waiting at another port.By analogy,people can receive messages by letter or by telephone.Telephone messages have higher priority than letters,though a second telephone call will not interrupt a call in progress.Multiple ports are not strictly required,though they do provide us with a mechanism for “interrupting”an actor while it is executing.Even with single-port actors we can model many kinds of object interactions.Object A invoking method M of object B can be easily understood as follows:Object A sends a CALL message to object B.When B receives the message,it prepares a response and sends a RETURN message to A. If there is a problem with A’s call,B sends back an EXCEPTION message instead.Furthermore, if A itself receives other CALL messages before B’s response,those messages are delayed until B returns.B’s response could also be directed to a separate port of A,thus avoiding the need to delay8What is the“Object”in Object-oriented Programming?messages.B might be acting as an agent for another object C.In that case,B would forward A’s message to C(including the informationC needs to send the response).C could then send its response directly to A,rather than through B.These protocols may be modiﬁed to allow,for example,recursion.Suppose that B wants to call some method of A before sending its response.If A delays all calls because it is expecting a response from B,then B’s call will never return.Recursion could be permitted by having A accept calls that it recognizes as originating from its own call to B.A“token”is thus passed around,which A will recognize when it receives a CALL message from B,or another intermediary.We can model transactions with message-passing as well.A transaction is a sequence of oper-ations on a collection of objects which is performed atomically,that is,either all of the operations are performed,or none of them(in case the sequence is aborted),and the intermediate states are not visible to other objects.Object A would,for example,ask object B to ignore calls from other objects while the transaction is taking place.A would then be guaranteed that B is not seen in an inconsistent state.By analogy,one can imagine the objects involved in a transaction as having a meeting behind closed doors.Anyone who is requested to join the meeting may enter the room, but no one may leave the room until the meeting is adjourned.Typically one may also“back out”of a transaction–if the meeting is aborted,then the participants return to their state before the meeting started.The CALL/RETURN message-passing protocol is followed as before,except that after returning,each object enters a“ready”state in which it is prepared to either commit or abort.At any time an object taking part in the transaction may issue an ABORT,which causes all participants to back up to a checkpointed state.(This message is broadcast along the already-established CALL/RETURN paths.)If the transaction completes without an abort being issued,the initiator of the transaction commits it by sending a COMMIT message to the participants(again,along the paths that the CALL/RETURN messages took).Nested transactions are a useful concept(meetings within meetings).Each object would then keep a stack of checkpointed states,one for each nesting level.(Note that it is not necessary to completely save each state,but only those parts that may be modiﬁed in the transaction.)Argus [12]is an example of a programming language that supports both data abstraction and nested transactions.Deadlock is still a real possibility.Consider two independent meetings,each of which suddenly requires the participation of someone in the other meeting.Also note that the success of the two-phase commit protocol outlined above assumes reliable message-passing and checkpointing.A real implementation would have to address these issues in an object-oriented environment,as it would in any other setting.As aﬁnal example,we can model triggering of activities by message-passing.Object A may send a SET trigger message to B,that says,“let me know when x happens”.Later,when x happens as a result of yet another object making a request of B,B may send a NOTIFY message to A. When A receives the notiﬁcation it initiates a new activity.A may also UNSET the trigger,telling B that it is no longer interested in x.A general triggering mechanism like this enables applications to know about interesting events without having to poll for them.The examples given in this section were not intended so much to show what kinds of mechanismsO.M.Nierstrasz9 are required for a concurrent object-oriented language or environment,but rather to indicate what the possibilities are,and how easily independent,message-passing objects can be mapped to an actor world.Since message-passing is the only medium for communication,it is also a natural step to map actors,and therefore objects,onto a heterogeneous environment of diﬀerent processors connected through a network.See[8]for a discussion of similar issues in an environment that supports synchronous message-passing.8Concluding remarks.The fundamental concepts in an object-oriented environment are data abstraction and inheritance.A programmer speciﬁes an interface to a new object type as a collection of methods which can be invoked.Separately,one deﬁnes the representation of the object’s state,and the implementation of the methods.The methods should be the only acceptable interface to an object.One must be able to create multiple instances of an object type.A subtype inherits the methods of its parent type,but not necessarily the implementation of the methods.If multiple inheritance is supported,a subtype may inherit methods from several parent types.The inheritance mechanism“overloads”methods,since methods apply to objects of diﬀerent (though usually related)types.In a fully object-oriented system,types are also objects,and one can instantiate new types at run-time.In a homogeneous design,expressions in the programming language are also objects, as are instance variables of an object’s permanent state,and even the messages objects use to communicate with.If concurrency and distribution are at issue,each object may be an active entity that sits“on top of”a message-passing process,called an“actor”.Examples of fully-integrated languages are Smalltalk[1,9,10]and Loops[13].Smalltalk does not support concurrency,distribution or multiple inheritance,but it does provide a strongly homo-geneous view of its language,in which even control structures are objects.Languages like Ada[2]support data abstraction,but no multiple instantiation or inheritance. It is impossible to add new types at run-time.Some languages like Lisp and C have been enhanced to give them some object-oriented ca-pabilities,without taking away anything that was in the language before.In the case of Lisp [14],“ﬂavours”,or traits have been added,so that one has both data abstraction and multiple inheritance.With Objective-C,(or its predecessor,OOPC),[5,6]a pre-processor was written that translates Objective-C object classes into C code,that can then be compiled by a regular C compiler.These two examples suggest that it is possible to program in an object-oriented“style”without actually using an object-oriented language.In fact,this can be done,though one would then not be able to make full use of inheritance or overloading of operations.Nor would one be able to add types at run-time unless an interpretable language(like Lisp)were used.As with any other programming style(procedural,applicative,logic-oriented...),one requires。

Fast Recompilation of Object Oriented Modules

a rXiv:cs /05635v1[cs.PL]1J u n25Fast Recompilation of Object Oriented Modules J´e rˆo me Collin and Michel Dagenais D´e partement de g´e nie informatique Ecole Polytechnique de Montr´e al C.P.6079,Succ.Centre-Ville Montr´e al,Qu´e bec,CANADA,H3C 3A7michel.dagenais@polymtl.ca February 1,2008Abstract Once a program ﬁle is modiﬁed,the recompilation time should be minimized,without sacriﬁcing execution speed or high level object oriented features.The recompilation time is often a problem for the large graphical interactive distributed applications tackled by modern OO languages.A compilation server and fast code generator were developed and integrated with the SRC Modula-3compiler and Linux ELF dynamic linker.The resulting compilation and recompilation speedups are impressive.The impact of diﬀerent language features,processor speed,and application size are discussed.Keywords:Compiler,Code generator,Dependency analysis,Persistent cache,Smart recompilation1IntroductionRecompilation speed is only one ingredient in the global picture of program-ming productivity.Nonetheless,its impact on programmer satisfaction is not1to be underestimated.Interpreters are sometimes seen as the solution for zero recompilation time.However,the modiﬁed module needs to be parsed into bytecode,which is not too diﬀerent from machine code,especially if the link editing phase is partially obviated by dynamic linking.The recompilation may be divided into the following phases.The smart recompilation phase determines the modiﬁedﬁles and computes the minimal set ofﬁles to recompile.The parsing and code generation phases convert the source codeﬁles into relocatable binaryﬁles.The prelink phase computes package wide information such as initialization order.Finally,the link phase combines all the relocatable binaryﬁles into a library or executable program.These phases are detailed in section2along with a discussion of the impact of diﬀerent language features on their complexity.This section mo-tivates the two main extensions brought by the authors to the DEC SRC Modula-3compiler[1],a compilation server and fast code generator,and reviews related work.Section3details the compilation server while section4describes the fast integrated code generator for Linux ELF[2].Section5presents the results obtained with the enhanced compiler,and outlines the contribution of each extension as well as the sensitivity to diﬀerent parameters.In the conclusion, the applicability of these results to other languages such as Java[3]and C++ [4]are discussed,and avenues for further development are examined.2BackgroundThe diﬀerent phases involved in recompiling a package,program or library, are detailed in this section.The work performed by typical compilers and by the DEC SRC Modula-3compiler,possible enhancements,and related work are discussed at key steps.The modiﬁcation time ofﬁles comprising a package are checked to deter-mine which ones were modiﬁed since the last compilation.Theseﬁles always need to be recompiled.In an integrated development environment,this in-formation may be provided by the editor,if all modiﬁcations are performed through it.If any type checking,or data structure member oﬀset computation,is performed at compile time,ﬁles have dependencies upon importedﬁles con-taining declarations.This is not the case for languages such as Smalltalk[5] or LISP,which defer type checking to runtime,but applies to Java,C++2and Modula-3.When one of the declarations used by aﬁle is changed,that ﬁle needs to be recompiled too.The use of a text level macro preprocessor,for importing declarations from otherﬁles,makes such dependency analysis extremely diﬃcult in C and C++.The traditional approach embodied by makeﬁle s is to recompile aﬁle whenever an includedﬁle was modiﬁed.The DEC SRC Modula-3 compiler remembers theﬁngerprint of each declaration used by a module, and recompiles the module only when any of the declarations used has a diﬀerentﬁngerprint.This muchﬁner grain dependency analysis,(at the level of individual type declaration instead of complete headerﬁle),explains in large part the smaller recompilation times typically associated with more structured languages,as compared to C/C++.Computing the minimal set ofﬁles needing recompilation is the smart recompilation phase and has been studied in[6],[7],[8],and[9].Any reduc-tion in the number ofﬁles to recompile,due to aﬁner analysis,has a direct impact on the total recompilation time.The set of modiﬁedﬁles,and ofﬁles potentially aﬀected by modiﬁcations inﬁles on which they depend,is recompiled in the parsing and code genera-tion piling the individualﬁles is often the most time consuming step.While minimizing the number ofﬁles to recompile is important,it is also possible to reduce the number of imported interfaces to parse,and to speedup the code generation phase.The DEC SRC Modula-3compiler already has a cache for imported inter-faceﬁles.Each imported interface is read at most once in each recompilation. Aﬁrst extension,described in section3,was to convert the compiler into a compilation server.This way,an importedﬁle may be kept in the interface cache and need not be read and reparsed if it did not change between two compilations.Koehler and Horspool[10]worked on a compilation server for the C lan-guage.Most of their eﬀort was spent analyzing the pre-processor context,to determine if the importedﬁle can be reused in diﬀerent importers.It requires a validation scheme rather diﬀerent than the one proposed here.Onodera proposed[11]a compilation server for a diﬀerent language,COB,which has 2kinds of interfaces,one similar to C and one similar to Modula-3.The code generation time is a signiﬁcant fraction of the total compilation time.A fast code generator for Linux ELF,based on an existing code gen-erator for NT in SRC Modula-3,is a second extension described in section 4.Tanenbaum et al.[12],and Fraser et al.[13]have obtained interesting3results with fast but lessﬂexible non optimizing backends.In the prelink phase,a number of application wide informations may need to be computed,to be used by the run-time system.Non OO languages like C had little or none such information.In Modula-3,the initialization order of modules(based on the modules dependency graph),the run time type information(after resolving type equivalence),the coherence of opaque types revelations,and the structures for checking inheritance relationships in constant time,are computed during this prelink phase.In Java,initialization order is determined at runtime.C++does not specify an initialization order and only recently started to oﬀer run time type identiﬁcation.Theﬁnal step,performed by the link editor,is assembling the object code of all the modules into theﬁnal executable.With dynamic linking,such as in Linux ELF[2],the amount of processing required is greatly reduced. All references internal to a module use position independent code and do not require further link editing.Moreover,links to libraries are resolved at execution time.Data symbols in libraries are resolved upon loading the executable but procedure references are resolved only when needed,as the execution proceeds.3Compilation ServerA compilation server reduces the recompilation time by maintaining some information across compilations,instead of reading and reparsing the cor-respondingﬁles each time.Imported interfaces represent the bulk of the information required when compiling aﬁle and often do not change from one compilation to another.Thus,the purpose of the compilation server is to maintain the interface cache across compilations.Implementing a compilation server for C/C++presents serious diﬃculties because of the preprocessor mechanism.For instance,the#ifdef in Figure 1can lead to two diﬀerent variables in the symbol table,depending on the value of DEBUG.Moreover,the compilation of an included.hﬁle does not lead to an independent objectﬁle.Instead,the object code associated with it is part of the relocatable objectﬁles produced by the compilation of“.c”ﬁles that include the“.h”ﬁle.In languages with explicit interfaces such as Modula-3,the content of an interface is not dependent on the importingﬁle and can be reused for several importingﬁles,even across compilations.Some languages such as Eiﬀel and4#ifdef DEBUG int x#else int y #endifFigure 1:#ifdef exampleE D library 1C B A library 2P new programor libraryt t tt t 0E &&&&&&bor indirectly imported interface is invalid,the interface is declared invalid.In the last case,theﬁne grain dependency analysis is used to determine if any declaration actually used by the interface has changed.If not,the interface is still valid.Otherwise,the interface is removed from the cache and will need to be read and parsed again.Thus,the validation algorithm is to recursively visit each imported in-terface in the graph to see if its associated sourceﬁle has been modiﬁed or if imported declarations have changed.A time stamp is used to mark each valid interface as valid for this recompilation.When the same interface ap-pears in the import graph of anotherﬁle,the time stamp indicates that it has already been checked as valid.The existing implementation of DEC SRC Modula-3did not have a validation phase since the interface cache was not kept across compilations.Any interface in the cache was necessarily parsed in the current compilation and therefore still valid.A further optimization is added for interfaces imported from separate li-braries(packages).Indeed,each package has an associatedﬁle containing the information used by the smart recompilation system.Any modiﬁcation to an interface in a library,and subsequent recompilation,changes the modiﬁcation time of the associatedﬁle.Thus,the modiﬁcation time of library interfaces is checked only if the associatedﬁle has changed.Many libraries being seldom changed,this simple optimization avoids a large number ofﬁle modiﬁcation time checks.The generic interfaces(the equivalent of the templates in C++) are not put in the cache because they don’t have a corresponding AST.Their instanciations,however,are eligible to be cached.Figures3and4show the general structure of the compiler before and after being transformed into a server.Libraries are represented as ovals and programs as rectangles.Import relationships are indicated by arrows. Programs executing other programs are shown with dashed lines.Packages m3front and m3back are the frontend and the backend respec-tively.M3linker is the smart recompilation system.Package m3contains the main procedure of the compiler.M3quake is a simple interpreter that parses the m3makeﬁles and passes parameters to the compiler(m3).M3build initiates the m3quake interpreter in the appropriate directory,inserts the platform and package dependent deﬁnitions,and sends the m3makeﬁle to m3quake.The connections to the two available code generators,and to the linker,were left out for simplicity.The existing compiler involved several processes which were merged in a single executable program calling upon several libraries.Packages m3and6m3buildm3quake m3m3linkerm3frontm3backm3middle“driver”m3client m3server m3quake m3m3linker m3front m3backm3middle q q q qE ¨¨¨¨¨¨%££££££ e e e e e e e e e s z ¡¡¡¡ Figure 4:Structure of the modiﬁed SRC Modula-3compiler4Fast Code GenerationPortable,retargetable,optimizing compilers such as gcc are built in several layers and construct abstract syntax trees,an intermediate language repre-sentation,and an assembly language ﬁle at diﬀerent stages during the com-pilation.Furthermore,the interface between the Modula-3frontend,written in Modula-3,and the gcc based backend introduces another intermediate representation.While the gcc based backend is retained to beneﬁt from its optimizing capabilities and wide range of supported platforms,an integrated code gen-erator may be used on some platforms for faster compilation during the edit compile debug cycle.The code generator is fed by the frontend with simple virtual machine instructions and generates object code directly.It cannot perform sophisticated optimizations or target multiple platforms.An existing code generator for NT under Intel 386was used as a base.It was modiﬁed to support Linux ELF object ﬁles [2],and to produce po-sition independent code and debugging information.Position independent code allows eﬃcient dynamic linking,another important ingredient for fast recompilation.Debugging information generation increases slightly the code generation time but is almost essential for adequately supporting the edit compile debug cycle.Figure 6a)shows a simple Modula-3procedure returning the sum of two8INTERFACE M3Server;IMPORT NetObj,Thread,Wr,Pathname,TextList;EXCEPTIONError(TEXT);TYPET=NetObj.T OBJECT METHODScompile(initprocedure is called by the frontend,and the6ﬁrst machine instructions are generated.This saves on the stack and initializes the registers used for setting up a new frame according to the calling convention.Figure7shows the structure of the stack frame constructed with these instructions.The ebp register(base register)is used to reference other values in the stack frame by specifying a4byte oﬀset in an indexed address mode.The stack frame also includes the arguments to the procedure,the return address of the calling procedure, the value of ebp for the previous stack frame,local variables,and some saved register values.Thereafter,the machine instructions corresponding to the body of the Modula-3procedure are generated.The load method is called twice by the frontend,once for each operand.No machine code is generated for this.In-stead,the operands are pushed on the operand stack in the data structures maintained by the code generator.The call of the method add by the fron-tend generates the code for adding the operands previously pushed on the stack.On the i386,at least one operand of add must be in a register.Thus,9PROCEDURE Add(i,j:INTEGER):INTEGER= BEGINRETURN i+j;END Add;(a)beginproc(...) end pushl%ebpmovl%esp,%ebppushl%ebxpushl%esipushl%edimovl0x8(%ebp),%edx addl0xc(%ebp),%edxmovl%edx,%eax popl%edipopl%esipopl%ebxleaveret(c)Figure6:Compilation of a simple procedure.one variable must be moved from its position in the stack frame in memory to a register(here edx).The other operand can be addressed directly in mem-ory by instruction add.The result of the addition must be returned to the calling procedure in register eax,as speciﬁed in the calling convention.Thus, the value in edx is moved to eax when method exitprocedure generates the code required to remove the stack frame and restore aﬀected registers.Several optimizations to the generated code would be possible.For exam-ple,the use of register edx could be avoided by using eax instead.This would obviate the need to transfer the return value to eax in the end.Registers ebx,esi and edi were needlessly saved and restored on the stack even if they were not used during the body of the procedure.Even though the fast code generator does not perform such optimizations,the generated code is still more eﬃcient than the naive code produced by gcc without optimization,as10M3frontcc cFigure8:Structure of the code generator.the memory consumed by the interface cache to represent the AST.All tests were performed on a75MHz Intel Pentium with32MB of main memory and running Linux2.0.All times are in elapsed seconds on a single user machine, and thus account for input/output delays.The performance of both the integrated backend and the compilation server were evaluated and compared to the original DEC SRC Modula-3 compiler version3.6.The compilation times for the original compiler are in Table2.Detailed measures were obtained for the various compilation phases using the compiler built-in timers.Column M3⇒I.L is the time required to trans-late Modula-3code into intermediate language,which is performed by the frontend.I.L.⇒ass.is the time needed by the gcc based backend(m3cgc1) to convert the intermediate language into assembly,and ass.⇒reloc.is the time taken by the assembler to produce a relocatable binaryﬁle.Table3presents the results for the compiler with the integrated backend instead of the gcc based backend.The fast code generator goes directly from the code generating method calls to the relocatable binaryﬁle,as indicated by M3⇒reloc.Since the code generation is performed at the same time as parsing,the time required for each phase is not available separately.12package memory compiled size lines*modules required columns47.17K13067 2.26M151127webscape11.72K3471 2.96M70051267webvbt194.76K536420 3.63M3035835m3front 1.367M39789171 3.06M1041812161ps2html315.85K919730 3.57M Table1:Packages used to evaluate the performanceTime(in seconds)M3⇒ass.⇒I.L.reloc.other4.21 4.440.32netobjd0.78 1.500.43 4.752.56 1.510.91m3browser 1.0436.09 1.1161.0114.1716.83 2.03m3tohtml0.7916.490.8529.1369,56108.0317.32postcard 2.7955.34 4.16101.8428.2427.34 1.48Time(in seconds)M3⇒reloc.other6.460.61 netobjd0.770.43 2.832.93 1.14m3browser0.970.8517.1921.60 2.02m3tohtml0.94 1.068.2295.5416.88 postcard 3.078.5144.4235.73 1.28Time(in seconds)M3⇒ass.⇒I.L.reloc.other1.96 4.450.26 netobjd0.46 1.520.44 4.041.58 1.550.65m3browser0.6337.19 1.5560.9112.0417.41 2.31m3tohtml0.4116.400.8628.2377.84121.0231.18 postcard 2.4857.737.32108.2724.7330.44 1.59Time(in seconds)M3⇒ass.⇒I.L.reloc.other0.970.860.22 serverwith m3cgc10.76 2.730.42 5.521.840.24 serverwith integrated0.640.42 2.62 Table5:Recompilation of postcard after modiﬁcations to2ﬁlesa degradation if memory is short.The picture improves however when the compilation server is combined with the fast code generator.Indeed,the 2.46s reduction for columns represents12.5%of19.66s but amount to27.1% of9.08s.These savings only involve the smart recompilation and frontend parsing phase,and are independent of the code generation time.The tests presented in Tables5and6are more typical of the edit compile debug cycle.They consist in recompiling a large graphical application,post-card,after2ﬁles,and4ﬁles,are modiﬁed.Four diﬀerent cases are covered: existing compiler and code generator,fast code generator,compilation server, compilation server with fast code generator.For these tests,the computer used had the same characteristics except a Pentium Pro180MHz processor and64MB of RAM.These tests clearly demonstrate that the compilation server and fast code generator contribute independently to the recompilation time reduc-tion.Their combined eﬀect in that case amounts to a reduction from9.77s to3.22s.This is especially impressive considering that the Modula-3compiler is already much more eﬃcient than most C/C++compilers,because of the interface cache andﬁne grain dependency analysis allowed by the structured interface mechanism.16Time(in seconds)M3⇒ass.⇒I.L.reloc.other1.89 1.680.20 serverwith m3cgc10.44 4.850.438.662.660.27 serverwith integrated0.510.42 3.22 Table6:Recompilation of postcard after modiﬁcations to4ﬁles6ConclusionA fast recompilation system for a modular,compiled,object oriented lan-guage was presented.It beneﬁts from the existing interface cache andﬁne grain dependency analysis,and was extended with a persistent interface cache,fast code generator,and Linux ELF dynamic libraries support.The resulting recompilation time reduction is impressive.For a large graphical application,recompiling after a fewﬁles were modiﬁed took3.22s instead of 9.77s.In the coming years,faster processors,larger main memory and more complex programs may be expected.The average size of eachﬁle,and the number ofﬁles modiﬁed between compilations are not expected to change signiﬁcantly however.The net eﬀect would be a gradual reduction of theﬁle parsing and code generation time,which currently dominates the recompi-lation time at2.05s out of3.22s.The smart recompilation and linking time accounts for much of the remaining time(.92s out of1.17s).These may be adversely aﬀected by the increasing programs complexity and eventually dominate the recompilation time.Increases in programs complexity are likely to change more the number of libraries imported by each program rather than the size of each program ﬁle or library.The smart recompilation system could accordingly be further optimized in several ways.More information about each imported library17could be cached,as applications importing more libraries have much larger times for the smart recompilation phase.A tighter integration between the program editor and the compilation server could allow the smart recompila-tion to perform most of its work incrementally.When aﬁle is opened and modiﬁed,the compiler could pre-compute whichﬁles are aﬀected,and need to be recompiled or dependency checked.When aﬁle is saved,the recompi-lation of thatﬁle and aﬀectedﬁles may proceed.Thus,when the lastﬁle is saved,only that lastﬁle,and theﬁles aﬀected,would need recompilation.Theﬁnal recompilation steps,prelinking and linking,involve the complete program and may therefore become the dominant step as program complexity increases.Interestingly,the Linux ELF linker is surprisingly eﬃcient for dynamically linked libraries.Only a small fraction of each library needs to be read by the linker.Yet,because of the lazy procedure linking algorithm used in ELF,the program startup penalty imposed by dynamic linking is small.As may be seen from the results,the linking time is mostly aﬀected by the package size rather than by the number of imported libraries.Linking is an I/O intensive process,and the availability of free RAM for the I/O buﬀer cache strongly impacts the elapsed time.This was appar-ent for large programs where the compilation server actually degraded the performance because of the competition for memory.Assuming suﬃcient physical memory,it may be possible to reduce the linking time by dynam-ically loading each objectﬁle as it is being recompiled.This would remove the linking step which reads all objectﬁles from disk,merges theﬁles into an executable,and writes the executable to disk,before loading the executable.The prelinking step,listed as other,currently uses a small fraction of the overall recompilation time.It checks the coherency of opaque types revela-tions,determines the modules initialization order,and generates the run time type identiﬁcation data structures.The processing time is proportional to the total number of modules in theﬁnal program.With increasing program complexities,this may in the long term become an important factor.In C++,run time type identiﬁcation is a recent addition and is likely to bring diﬀerent problems.Indeed,a declaration appearing in a.hﬁle may be included and compiled several times.The prelinker must ideally remove duplicate virtual methods tables and run time type information.The Java language does not specify a static initialization order nor does it have opaque types to check.The prelinker step is thus mostly avoided.However,since a class must be initialized at itsﬁrst active use,many tests must be inserted at run time to initialize classes when they are used,if it is theﬁrst time.Thus,18the savings in the prelink phase are oﬀset by the run time overhead.The fast code generator is now part of the freely redistributable Polytech-nique Montreal Modula-3distribution,originally found at http://m3.polymtl.ca/m3/pkg but now hosted at /pm3/,and received enthusias-tic feedback from users around the world.The compilation server is available separately at http://www.professeurs.polymtl.ca/michel.dagenais/pkg/m3server.tar.gz. AcknowledgmentsTheﬁnancial support of the National Sciences and Engineering ResearchCouncil of Canada,as a scholarship to theﬁrst author,while he was a mas-ter’s student at Ecole Polytechnique de Montreal,and an operating grant tothe second author,is gratefully acknowledged.This work would not havebeen possible without the excellent environment provided by the DEC SRCModula-3compiler.Bill Kalsow,Allan Heydon,and Greg Nelson contributedto this project through numerous technical discussions.References[1]G.Nelson,Systems Programming with Modula-3.Innovative TechnologieSeries,Englewood Cliﬀs,NJ:Prentice Hall,1991.[2]boratories,System V Application Binary Interface–Intel386Architecture Processor Supplement.Unix Press,1993.[3]J.Gosling,B.Joy,and G.Steele,The Java Language Speciﬁcation.Reading,Massachusetts:Addison Wesley,1996.[4]B.Stroustrup,The C++Programming Language.Reading,MA:Addison-Wesley Publishing Company,1992.[5]A.Goldberg and D.Robson,Smalltalk-80:The Language and its Im-plementation.Reading,Massachusetts:Addison Wesley,1983.[6]W.F.Tichy,“Smart recompilation,”ACM Transactions on Program-ming Languages and Systems,vol.8,pp.pages273–291,July1986.19[7]R.Adams,W.Tichy,and A.Weinert,“The cost of selective recom-pilation and environment processing,”ACM Transactions on Software Engineering and Methodology,vol.3,pp.pages3–28,January1994. [8]M.A.Linton and R.W.Quong,“A macroscopic proﬁle of programcompilation and linking,”IEEE Transactions on Software Engineering, vol.15,pp.pages427–436,April1989.[9]J.Gutknecht,“Separate compilation in Modula-2:An approach to eﬃ-cient symbolﬁles,”IEEE Software,vol.3,pp.pages29–38,November 1986.[10]B.Koehler and N.Horspool,“CCC:A Caching Compiler for C,”paratredans:Software–Practice and Experience,January1997.[11]T.Onodera,“Reducing compilation time by a compilation server,”Software–Practice and Experience,vol.23,pp.pages477–485,May1993.[12]A.S.Tanenbaum,M.F.Kaashoek,ngendoen,and C.J.Jacobs,“The design of very fast portable compilers,”SIGPLAN Notices,vol.24, pp.pages125–131,November1989.[13]C.W.Fraser and R.R.Henry,“Hard-coding bottom-up code genera-tion tables to save time and space,”Software–Practice and Experience, vol.21,pp.pages1–12,January1991.[14]A.Birrell,G.Nelson,S.Owicki,and E.Wobber,“Network Objects–Report115,”Systems Research Center Digital Equipment Corporation 130Lytton Avenue Palo Alto,Californie,U.S.A.,94301,February1994.ftp:///pub/DEC/SRC/research-reports/SRC-115.ps.Z.[15]J.Collin,“Compilation par serveur persistant et g´e n´e ration rapide decode,”Master’s thesis,Ecole Polytechnique de Montr´e al,January1997.20。

Object-oriented Design

Software Engineering, 6th edition. Chapter 12 Slide 3
©Ian Sommerville 2000
Topics covered

Objects and object classes An object-oriented design process Design evolution
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 12
Slide 9
Objects（对象）
An object is an entity which has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.

19面向对象数据模型_19_

OBJECT-ORIENTED DATA MODELING
Principles the things in the world are instances of classes John Smith - human being State Street - street Santa Barbara - city Mt Everest – mountain classes form hierarchies John Smith is an instance of the class male
e.g., procedure to annotate contours specific interaction rules between objects
e.g., a liquor store cannot be within 500m of a school e.g., an offramp is required if a street and a freeway intersectபைடு நூலகம்e.g., at least one stream must flow out of every stream junction instances of a class must share: same topological dimensions / same attributes / same behaviors
➢ Classification ➢ Generalization ➢ Aggregation
Classification
is an abstraction from individuals with common properties to a class (instance_of_relation)

ch07_Design and Implementation

Chapter 7 Design and implementation 4
An object-oriented design process
• Structured object-oriented design processes involve developing a number of different system models. • They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective. • However, for large systems developed by different groups design models are an important communication mechanism.
• The Transmitter and Receiver objects are concerned with managing communications and the WeatherData object encapsulates the information that is collected from the instruments and transmitted to the weather information system. • This arrangement follows the producer-consumer pattern, discussed in Chapter 20.
– – – – – Define the context and modes of use of the system; Design the system architecture; Identify the principal system objects; Develop design models; Specify object interfaces.

软件工程题库7

From Modules to Objects1. Object-oriented concepts are not new. The first OO language was Econsidered to be:A. ALGOL-68B. FORTRAN 77C. CD. MODULAE. SIMULA 672. A lexically contiguous sequence of program statements, terminated by boundary elements, having an aggregate identifier. This is a definition of a:A. procedureB. functionC. moduleD. methodE. all of these3. If software is not modular it is difficult to:A. correctB. enhance or extendC. understandD. reuseE. all of these4. The degree of interaction within a module is known as:A. cohesionB. adhesionC. bindingD. couplingE. instantiation5. The degree of interaction between two modules is known as:A. cohesionB. strengthC. inheritanceD. couplingE. instantiation6. A method of implementing common coupling is:A. the common statement in FORTRANB. the common statement in COBOLC. the global statement in COBOL-80D. the C++ or Java modifier publicE. all of these7. The use of common coupling has an inherent limitation.A. The code is virtually unreadableB. Modules have side effects that affect their readabilityC. If a change has to be made to the declaration of the global variable in one module then it must be made in all modules accessing it.D. Modules are difficult to reuse as an identical list of global variables hasto be supplied each time it is reused.E. It is exposed to more data than it needs.F. All of these8. Data encapsulation is an example of:A. generalisationB. specialisationC. abstractionD. couplingE. dynamism9. Without __________________, the definition of an object as an instantiation of an Abstract Data Type is too simplistic.A. polymorphismB. bindingC. encapsulationD. inheritanceE. dynamism10. A class is an Abstract Data Type that supports:A. polymorphismB. bindingC. encapsulationD. inheritanceE. dynamism11. Why can't the Object-Oriented paradigm be directly implemented in classical languages such as C, COBOL and FORTRAN?A. they are not structuredB. there is not a mechanism for defining global variablesC. all of these reasonsD. inheritance and the notion of class are not supportedE. none of these reasons12. Parent is a ____________ of HumanBeing.A. specialisationB. abstractionC. polymorphismD. generalisationE. implementation13. ___________ refers to the components of a class:A. specialisationB. abstractionC. polymorphismD. generalisationE. aggregation14. The relationship of some kind between two apparently unrelated classes is referred to as a(n):A. specialisationB. associationC. polymorphismD. generalisationE. aggregation15. The relationship between a derived class (or subclass) and base class is referred to as:A. associationB. inheritanceC. polymorphismD. instantiationE. aggregation16. An act of connecting an object to the appropriate method is called:A. dynamic bindingB. inheritanceC. polymorphismD. generalisationE. aggregation17. If a method can be applied to objects of different classes it is termed:A. dynamicB. inheritedC. polymorphicD. generalisedE. aggregated18. Why can polymorphism and dynamic binding have a negative impact on inheritance?A. This statement is not true. Like all object-oriented concepts polymorphism and dynamic binding make modules more cohesive and lower coupling.B. They make the object harder to understand as there are multiplepossibilities for a specific method.C. They involve more work as changes have to be made to the super class.D. They involve more work as changes have to be made to all of the subclasses.E. All of these reasons impact maintenance.19. Myers (1978) identifies seven levels of cohesion. Which level of cohesion may be defined as followed; "the output from one element in the component serves as input for some other element"?A. None of theseB. Functional cohesionC. Communicational cohesionD. Temporal cohesionE. Communicational cohesion20. Myers (1978) identifies seven levels of cohesion. Which of the following is the strongest form of cohesion?A. Functional cohesionB. Communicational cohesionC. Sequential cohesionD. Logical associationE. Coincidental cohesion21. In FORTRAN the use of the COMMON blockA. results in a high degree of coupling.B. results in a high degree of cohesion.C. allows one to gain leverage through the reuse of the FORTRAN Subroutine library.D. is used to implement inheritance.E. is used to implement encapsulation22. Which of these characteristics should a good design have?A. The design should be the most maintainableB. The design should allow efficient code to be producedC. The design should have compact implementationD. The design should correctly implement specificationsE. All of these23. Myers (1978) identifies seven levels of cohesion. Which of the following cohesion levels has the highest strength?A. Procedural cohesionB. Logical associationC. Temporal cohesionD. Sequential cohesionE. Coincidental cohesion24. How does inheritance in an object-oriented design affect its understandability?A. Inheritance affects understandability in both positive and negative ways.B. Inheritance may be used to conceal design details.C. Inheritance always improves understandability.D. Inheritance spreads information around the design thus degrading understandability.E. Inheritance always degrades understandability.25. Of the following the strongest level of cohesion in software design is:A. SequentialB. LogicalC. FunctionalD. ObjectE. Procedural26. Which one of the following statements is FALSE?A. Function-oriented design and object-oriented design are complementary design strategies.B. All of these statements are correct.C. Object-oriented decomposition models the system as a set of objects.D. Cohesion is a measure of how closely the components of a system are interconnected.E. Functional decomposition involves modelling a system as a set of interacting functional units.27. Object-oriented languages are so effective for rapid prototyping because ___A. fewer Lines Of Code (LOC) are required to produce a Function Point (FP) than for other comparable languages.B. they were designed to be in used with modern techniques such as Joint Application Development (JAD) and Rapid Application Development (RAD).C. the components can be readily adapted by creating new (sub-) components that inherit the attributes and operations of the original component.D. they are more efficient and modern than older languages.E. components are easier to understand as they are added to the inheritance network.28. A design is said to be a good design if the components are:A. Strongly coupledB. Weakly cohesiveC. Strongly coupled and Weakly cohesiveD. Strongly coupled and strongly cohesiveE. Strongly cohesive and weakly coupled29. Cohesion is a measure of how closely the parts of a component relate to each other and Coupling is a measure of the strength of component interconnections. Designers should aim to produce:A. Strongly cohesive designsB. Weakly coupled designsC. Strongly coupled designsD. Weakly cohesive designsE. Strongly cohesive and weakly coupled designs30. The two main design strategies are known as functional design andobject-orientated design. Which of the following statements is false?A. In an object-orientated design the system state is decentralised and each object manages its own state information.B. In functional design the system state is centralised and state informationis accessed by different functions.C. Functional and object-orientated approaches are complementary techniques.D. the most appropriate design strategy is selected for each stage of design, there is no need to adhere to a single approach during the whole design process.E. The same design approach must be used in the design of different system components to ensure consistency, especially for large software systems.31. Which of the following levels of component cohesion strength is the lowest?A. Procedural cohesion.B. Sequential cohesion.C. Functional cohesion.D. Temporal cohesion.E. Coincidental cohesion.32. The measure of the closeness between components of any module is known as cohesion. The cohesion in which the components are NOT related but are simply bundled is known as:A. Temporal cohesion.B. Functional cohesion.C. Communicational cohesion.D. Coincidental cohesion.E. Sequential cohesion.33. Which of the following is NOT one of the seven levels of cohesion?A. Procedural cohesionB. Logical associationC. Temporal cohesionD. Object cohesionE. Coincidental cohesion34. Communicational cohesion is where:A. components that perform similar functions such as input, error handling and so on are put together in a single component.B. the elements in a component make up a single control sequenceC. all of the elements of a component operate on the same input data or produce the same output data.D. all of the elements in a component make up a single control sequence.E. the output from one element in the component serves as input for some other element.35. Experience of object-oriented programming has shown that the inheritance network must be periodically reviewed and restructured ____________ .A. to increase it's coupling and decrease its cohesion.B. in order to improve its processing efficiency.C. this statement is not true, if you design it right, then it only needs to be extended.D. to reduce its complexity and functional duplication.E. to decrease it's coupling and increase its cohesion.36. Which of the following levels of cohesion, as identified by Myers (1978), allows components to perform similar functions such as input and error handling to be put together into a single component?A. Temporal cohesionB. Sequential cohesionC. Communicational cohesionD. Logical associationE. Coincidental cohesion37. Temporal Cohesion is where:A. the elements in a component make up a single control sequenceB. components activated at a single time are brought togetherC. components that perform similar functions are put into the same componentD. parts of a component are unrelated but placed into a single component anywayE. None of these relate to Temporal Cohesion38. If a control switch is passed as an argument this is an example of _______ coupling.A. contentB. commonC. controlD. stampE. data39. If one module directly references the contents of another they are said tobe _______ coupled.A. contentB. commonC. controlD. stampE. data40. If a data structure is passed as an argument, but the called module operates on only some of the individual components of that data structure then they are said to be _______ coupled.A. contentB. commonC. controlD. stampE. data41. If every argument is either a simple argument or a data structure in which all elements are used by the called module then they are said to be _______ coupled.A. contentB. commonC. controlD. stampE. data42. Which of the following is a type of abstraction?A. dataB. proceduralC. iterationD. all of theseE. none of these43. The problem that once a class has been implemented, any change to an existing class directly affects all is descendents in the inheritance hierarchyis known as:A. the fragile base class problemB. polymorphismC. overridingD. information hidingE. data abstraction。

European Simulation Symposium, 1997 SIMOO- An Environment for the Object-Oriented Discrete

European Simulation Symposium, 1997 SIMOO - An Environment for the Object-Oriented Discrete SimulationCopstein, Bernardo1,3 Wagner, Flavio R.1 Pereira, Carlos E.21Informatics Institute 2Eletrical Engineering DepartmentUniversidade Federal do RioGrande do SulCaixa Postal 1506491501-970, Porto Alegre, RS, Brasil3 Informatics Institute - Pontif’cia Universidade Cat—lica do RGSCaixa Postal 1429,90619-900, Porto Alegre, RS, BrasilE-mail: copstein@inf.pucrs.br flavio@inf.ufrgs.br cpereira@iee.ufrgs.brKEYWORDSDiscrete Simulation, Object Oriented Simulation, Interactive Simulation.ABSTRACTThis paper describes SIMOO, an object-oriented framework for discrete simulation. Simulation entities in SIMOO are mapped to autonomous elements, that are objects with their own thread. Objects communicate with each other through non-typed messages. SIMOO models are built using a graphical editor called MET. MET uses a hierarchical class diagram, enriched with specific features for simulation. For instance, it allows the specification of the simulation paradigm which is more adequate for each entity. Besides a hierarchical class diagram, instance diagrams are also described, where the generic specifications of class diagrams are particularized. From the specified diagrams and from the description of the entitiesÕ behavior, MET generates an executable model which uses a class simulation library.1.INTRODUCTIONThe use of object orientation in simulation is widely discussed in the literature [ARO93, CHA94]. In fact, SIMULA [BIR73], which, as the name indicates, was oriented towards simulation, was the first language to use object-orientated concepts. This symbioses between object orientation and simulation can be mainly explained by the fact that simulation models are usually considered as a collection of interacting entities, so that the use of object orientation in the construction of such models is quite natural.The description of a simulation entity includes static aspects, such as the definition of its characteristics and state, as well as dynamic aspects, such as how an entityÕs state evolves along time. The static part is represented as a collection of data objects and their possible values [COT92], while the dynamic structure is more complex and involves aspects such as the representation of the events that modify the system state, the resources for the communication between entities, and the viewpoint from which the entitiesÕ behavior is described. These three aspects are orthogonal to each other and various combinations of their implementation alternatives can be used to describe the behavior of a particular simulation entity.When mapping entities to objects, some aspects must be considered. According to Booch [BOO94], the state of an object is described by the set of its data attributes and their possible values. Abell and Judd [ABE93], however, signal that the state of a simulation entity is defined by the subset of the attributes of the object which are specifically used to describe the entityÕs behavior. Regarding the messages, in object-oriented models a message usually corresponds to the activation of a process within the object receiving this message. In simulation models, however, message exchanging is more complex. Messages must have time stamps to allow the scheduling of future events. Non-timed messages are useful only for querying object attributes or for triggering actions that do not imply time advancing. Complex message queuing systems and the use of selection primitives may be found in the simulation literature (see e.g. [BAE91]). Considering these two aspects, Cota [COT92] defines two types of entities: passive receiver entities, where the message sender determines the time point when the receiver must process the message, and active receiver entities, where messages are stored in a buffer for later processing.Several simulation environments which try to explore object-oriented concepts have been presented in the literature. SMOOCHES [BAR96] is a general-purpose simulation environment which offers a high-level language for representing hierarchical, object-oriented system characteristics. It uses graphical notations for both the class model and the behavior description of the entities. ExSim [ZHE93] uses a programming model based on a block diagram for representing system components and classes for representing the components behavior. Information exchange between blocks is done by messages that flow through communication channels defined by input / output ports. Finally, VMSS [KAM96] explores VIM (Visual Interactive Modeling) and VIS (Visual interactive Simulation) in an environment oriented towards the simulation of flexible manufacturing systems.Most of the authors, however, present their ideas based on a single simulation modeling paradigm, such as message orientation [CHA94], queue orientation [VAU91], or event orientation [BAR96, ABE93]. There is no concern in distinguishing the paradigm adopted for model design/implementation, which is object orientation, from the simulation paradigm. As a consequence, these approaches do not offer the flexibility to choose the simulation paradigm according to the problem to be solved. Furthermore, it can be observed that the highest degree of interaction between the user and the model is found in environments with specific purposes. When the generality of the environment increases, the degree of interaction usually decreases.Considering all those aspects, SIMOO, a framework [GAM95] specially oriented towards the development o f discrete simulation models, has been designed. SIMOO differs from other approaches, because it allows the selection o f the most adequate simulation paradigm for each particular entity in the model. This selection takes into account the different aspects that compose each simulation paradigm. SIMOO makes a clear distinction between the paradigm for model design, which is object orientation, and the various traditional simulation paradigms (such as event and process orientation) it supports [COP96]. Besides that, SIMOO explores meta-classes [BOO94] and meta-objects as a way to achieve a maximum degree of interaction between the user and the model, without forcing the model developer to consider and implement this interaction .This paper is organized as follows. Section 2 discusses the modeling principles of SIMOO, that are implemented in a class library. Section 3 introduces a graphical tool for model building. Finally, Section 4 draws conclusions and discusses future directions of research.2. SIMOO MODELING PRINCIPLESSIMOO is an integrated environment for modeling and simulation of discrete systems. It is composed by two main modules: the class library and the model editor. The editor supports the description of static and dynamic aspects of the model. In the current version of SIMOO, structural aspects are described graphically, while the dynamic behavior of each entity is described in C++ using library resources. From model description, the editor automatically generates the necessary executable code. It also supports the construction of a library of autonomous elements, which may evolve as new models are developed. Figure 1 presents this main software architecture.SIMOO uses object-oriented concepts and enforces a hierarchical modeling of the system to be simulated. At the highest abstraction level there is a single entity representing the whole system under simulation. This entity is further necessarily refined at lower abstraction levels, thus building an aggregation hierarchy. Such modeling strategy aims at an easier reuse of entities, as well as a progressive refinement when it is needed.Figure 1 - SMOO architectureA model is assembled by Òinterface elementsÓ and Òautonomous elementsÓ. Interface elements allow the tracking of the simulation execution, supporting the visualization of simulation results, the interactive input of data, and the dynamic modification of parameters during experimentation. Autonomous elements, on the other side, are used to model entities. An autonomous element is an active object [WIL94], i.e., an object with its own execution thread and a message queue. Autonomous elements may interact with other autonomous and interface elements only through message passing. The model does not support shared variables, so that it may be also used in distributed environments.Messages have an identifier which is unique only in the context of the class where it is defined. There is no previous type checking in message exchange. When an autonomous element receives a message, it only verifies if there is a handling procedure defined for the received identifier. This approach eases the reuse of entities, because no restrictions are imposed on the types of autonomous elements that may communicate with each other. Therefore, each autonomous element may communicate with any other element. Indeed, since all possible relationships between classes of autonomous elements are defined in the so called class diagram, one is able to verify consistency during simulation. Messages sent to a particular entity are queued and served when the entity is available. The concurrent execution o f several autonomous elements is synchronized by the simulation clock.Either the way how an entity communicate with others, as well as how its behavior is described, depends on the simulation paradigm which is individually chosen for each entity. The current version of SIMOO allows a combination of the following approaches: event orientation or process orientation for the description of the entitybehavior, and messages or ports for the communication between entities. These approaches may be extended or specialized by inheritance (for more details on the simulation approaches see [COP96]).SIMOO also uses the concepts of meta-classes and meta-objects, specially for visualization. Meta-classes describe the structure of a class while meta-objects concentrate on the individual aspects of each object. By making reflexive all the autonomous elements, we build an structure that considerably ease the interaction between the user and the model during experimentation, while keeping separated two distinct domains: the autonomous elementsÕ behaviors and the degree of interaction they accept. At any given moment, the user may inspect or modify the contents of entity attributes and of the event list, may insert or remove relationships, and may create or destroy entities. Even the entity behavior may be modified during simulation, by replacing the object method which responds to a given message. This functionality is also extended to the interface elements, so that the user may not only configure the kind of information he/she wants to track during experimentation, but also the visual aspect to be associated to this information. This configuration, which may be dynamically modified, can be defined independently from the original model built by the user.Finally, SIMOO contains the usual facilities one expects from simulation environments, such as random number generators, probability distributions, and gathering of statistics.3. THE MODEL EDITOR TOOLMET (ÒModel Editor ToolÓ) is a tool for building complex simulation models which offers an interactive programming environment, supports the construction of hierarchical, object-oriented models, and stimulates reuse both of code and design.Since the main objective of SIMOO is the generation of executable models, features that are specific to discrete simulation models must be expressed using MET. Among those features, one can highlight the possibility of choosing different modeling paradigms for each entity (ports or messages, processes or events), since this choice impacts the way how we describe the entity behavior and the communication between entities. MET proposes some extensions to those diagrams that are usually proposed by object-oriented methodologies, such as class and behavior diagrams, in order to better handle simulation-related features.In its current version, structural information is depicted graphically in SIMOO by means of a class diagram and an instance diagram. The behavioral model is described by filling pre-defined templates and by generating C++ code for the methods for each object. The executable simulation code is then automatically generated by the editor.3.1 The Class DiagramIn MET a model specification always starts with the definition of the corresponding class diagram. This diagram is similar to those usually employed in object-oriented analysis methodologies. It allows the classification o f the several entities that are described in the model, as well as the relationships between these classes. SIMOO, however, extends these diagrams so as to allow the graphical specification of simulation-related aspects.The class diagram of a SIMOO model is built in a hierarchical way. Different hierarchy types may be identified: aggregation, inheritance, and refinement. Classes that are defined at a given level are considered to be components of the upper class which is being detailed.Figure 2 - Neander class diagramAs example, Figure 2 presents the first refinement level of the class diagram of a small, hypothetical processor called Neander. In this diagram we may recognize rectangles identifying classes (such as ALU, MPX, etc.), as well as the relationships between classes. Icons on the right-hand side of a rectangle indicate the simulation paradigm which has been chosen for that particular class. Figure 3 shows the repertory of icons corresponding to the various modelingapproaches available. A rectangle with a thicker margin indicates that the class contains components that are refined in a sub-diagram.Figure 3 - Simulation Modeling ApproachesThe class diagram allows the representation of four types of relationships: inheritance, aggregation, acquaintance, and creation. The meaning of these relationship types is based on the usual definitions found in object-oriented methodologies (e.g. [BOO94,GAM95]). Inheritance is a relationship among classes wherein one class shares the structure and/or behavior defined in one or more classes. Aggregation implies that an entity aggregates component-classes that are Òpart ofÓ the aggregator class. Acquaintance relationships denote that objects of a given class know objects from another class (and in this way they can communicate with each other). This kind of relationship is sometimes called ÒassociationÓ or ÒuseÓ. At last, creation relationships denote the relationship between a class X and the class which generates objects of class X.The arcs corresponding to acquaintance relationships are not directly connected to the classes in the diagram. Connections are done through connection points. These points may be of two different types, messages and ports, depending on the communication approach selected for the entity, and reflect the behavior we expect from the approach they represent.Referenced classes are another facility for building class diagrams. Class declarations are graphically visible only in the context where they are declared. However, any class may be referenced (reused) in different sub-diagrams. When this need arises, a meta-level is created, where the referenced classes are represented. Once defined at this meta-level, a class may be referenced from within any sub-diagram, as it had been declared there.Finally, the editor offers facilities for the creation of libraries of autonomous elements. Any autonomous element of a model may be "exported" at any moment during the model construction. An exported element is stored in a separate place, together with its ancestral classes (classes from which it is derived). Classes in this condition may be "imported" by any other model. The "import" operation checks whether classes already belong to the model, importing only those that are still unknown. In this way, two or more classes that are derived from a common ancestor and have been separately exported may be imported by a same model, but the common ancestor will be loaded only once.3.2 The Instance DiagramAlthough it presents some particular features, the class diagram is very similar to those usually found in object-oriented methodologies. However, a special characteristic of SIMOO is that the user must also necessarily create an instance diagram, from which the executable simulation model will be generated.Considering again Figure 2, one can easily recognize that from this single diagram many different processors may be generated. One can for instance vary the number and function of the registers. In order to simulate the model, it is necessary to create a particular processor. This is achieved with an instance diagram. In this diagram, entities of a particular model are specified and their relationships are detailed. Figure 4 shows the instance diagram of the Neander processor, containing one memory, four registers of class REGISTER and one register of class IR, one ALU, etc.Figure 4 - Neander instance diagramAnother aspect reinforcing the need for an instance diagram is the utilization of parameterized classes. In general, sets of classes sharing common attributes, but differing in some aspects, are described by inheritance hierarchies, such as in the case of the hierarchy headed by the class FUNCT_ELEM, in Figure 2. In certain cases, however, the differences do not justify such hierarchy and are more easily modeled by instantiation parameters. The size of a memory and the clock frequency are examples of such parameters, in the example of the Neander processor. The class is described by general parameters in the class diagram, and concrete values must be assigned to these parameters when the class is instantiated in the instance diagram.Figure 5 - Ambiguous class diagramFinally, there are situations where the class diagram may result in different structures when the instantiation is defined. Figure 5a presents a class diagram where class C1 has a 1-to-2 relationship regarding class C2. The instance diagrams shown in Figures 5b and 5c may be both generated from this same class diagram, but have different structures that are due to different interpretations of the relationship between C1 and C2.The need for an instance diagram is based on the fact that concrete simulation entities correspond to objects, and not to classes.3.3 Describing BehaviorAs already mentioned, in the current version of MET the behavior of the classes is described in C++. The window for editing the behavior (see Figure 6) is activated from the class diagram by a double click of the mouse upon the class whose behavior one wants to specify or modify.The window for editing the class behavior contains three forms: Routines, Attributes, and Inherited Routines and Attributes. The Routines form may be seen in Figure 6. It allows the definition of the routine headings (upper left box), the corresponding activation messages (upper right box), and the routine code itself (lower box). In the case of a routine which is not activated by a message, the constant NULL is indicated in the upper right box. The Attributes form support the edition of the attributes that are needed for specifying the class behavior. Finally, the Inherited Routines and Attributes form allows the visualization (but not the modification) of the routines and attributes that are inherited from ancestor classes.Figure 6 - Behavior editing window4. CONCLUSIONS AND FUTURE WORKSIMOO is a general-purpose, discrete simulation framework, which explores different modeling approaches, computational reflection, and autonomous entities for building simulation models. The choice of the most adequate modeling approach for each entity of the same model and the use of object orientation considerably increases the reuse o f entities. The utilization of autonomous elements besides easing the modeling of real world concurrency allows the execution of the model also in distributed environments. Finally, computational reflection allows a more powerful interaction between user and model and an easier implementation of this interaction.SIMOO has been applied as a modeling and simulation tool in different applications, varying from processor to manufacturing systems. Such experiences have allowed the validation of its generality and usefulness. Additional work is underway for generating code for the language of autonomous objects AOC++, thus supporting the simulation o f systems in real time. An application in this direction will be the construction of "virtual experiments" for the Industrial Automation Laboratory of the Electrical Engineering Department of the UFRGS.In the continuation of this research several aspects are being considered, such as an improvement of the mechanism for distributed simulation, looking for a less conservative approach for the synchronization of entities; extension of the set of modeling paradigms; implementation of persistent objects so as to save and restore the simulation status; control of model versions; and better support for statistical analysis.Bibliography[ARO93] Arons, Henk de Swaan. Object Orientation in Simulation. European Simulation Syposium, SCS, 1993. [ABE93] Abell,Jefferey A., Judd, Robert P. Reusable Simulation Object Specification Through Arbitrary Message Passing and Aggregation Scheme. Object Oriented Simulation, SCS, 1993.[BAE91] Baezner, Dirk; Lomow, Greg. A Tutorial Introduction to Object-Oriented Simulation and Sim++. In: Winter Simulation Conference, Phoenix, Arizona, SCS, 1991.[BAR96] Barcio, B. T., Ramaswamy, S., Macfadzean, R & Barber, K. S. Object Oriented Analysis, Modeling and Simulation of a National Air Defense System. Simulation 66:1, 5-21, USA, 1996.[BIR73] Birtwistle, G. M. - SimulaBegin. Lund Student Littrature, N.Y., 1973.[BOO94] Booch, Grady. Object Oriented Analysis and Design. The Benjamin/Cummings Publish Company, Inc., New York, 1994.[CHA94]Chang, W; Jones, L. R. Message Oriented Discret Event Simulation. Simulation, august 1994, pgs. 96 a 104.[COP96] Copstein, Bernardo; Pereira, Carlos Edardo; Wagner, Flavio R. The Object Oriented Approach and the Event Simulation Paradigms. In: 10th European Simulation Multiconference. SCS, Budapest, Hungary, june 2-6, 1996[COTA92] Cota, Bruce A.; Sargent, Robert G. A Modification of the Process Interaction Wold View. ACM Transactions on Modeling and Computer Simulation, vol. 2, nro. 2, april 1992, pgs. 109-129.[GAM95] Gamma, Erich; Helm, Richard; Johnson, Ralph e Vlissides, John. Design Patterns - Elements of Reusable Object Oriented SoftwareÓ. Addison Wesley. USA, 1995.[KAM96] Kamigaki, T., Nakamura, N. An Object-Oriented Visual Model_Building and Simulation System for FMS Control. Simulation 67:6, 357-385, USA, 1996.[VAU91] Vaughan, P. W. PRISM: An Object Oriented System Modeling Enviroment in C++. Object Oriented Simulation, SCS, 1991.[WIL94] Wilhelm, Bob. Structural Implications of Concurrent Execution Models for OO Real Time Systems. In: OOPSLAÕ94 - Workshop Proceedings, Portland, october, 1994.[ZHE93] Zheng, Q., Chow, P. A General Purpose Object-Oriented Enviroment for Discret-Event Simulations Obect Oriented Simulation, SCS, 1993.。

183_Overture_01

develop computational “objects” that represent fundamental abstractions of ele-ments in a computational model. In the structured approach, the fundamental unit of code is a subroutine or function that modifies the data in some way,where in the object-oriented approach,the fundamental unit is an objectdescribed by a class in C++. A class con-tains both data that describe the object and functions that operate on those data. In Overture, object-oriented design principles have been used throughout to hide the details of complex data structures and algorithms and their par-allel implementation. Data structures and algorithms can be specialized and extended through derivation. TheUCRL-TB-132077 Rev. 2URL: /casc/Overture/offs for using this method are signifi-cant, but the implementation details can be complex due to the intricacy of both the overall algorithm and the physics behind the simulation.The Overture FrameworkWhile it is possible to use traditionalstructured programming approaches to implement, debug, modify, and maintainapplications codes based on the adaptive composite overlapping grid method, this would be a daunting task, particularly on parallel computers. The Overture frame-work was developed usingobject-oriented design techniques and with the C++ programming language.With object-oriented design, the task is toOvertureObject-Oriented Tools for Solving CFD and Combustion Problems in Complex Moving Geometry TechnologyOverture is an object-oriented code framework for solving partial differen-tial equations in serial and parallel computing environments. It provides a portable, flexible software development environment for applications that involve the simulation of physical processes in complex moving geome-try. It is implemented as a collection of C++ libraries that enable the use of finite difference and finite volumemethods at a level that hides the details of the associated data structures, as well as the details of the parallel imple-mentation. While maintainingperformance equivalent to hand-coded C or Fortran, Overture is designed for solving problems on a structured grid or a collection of structured grids. In particular, it can use curvilinear grids,adaptive mesh refinement, and the composite overlapping grid method to represent problems involving complex domains with moving components.The method of adaptive com-posite overlapping grids provides a computationalmechanism to accurately simulate phys-ical processes that are described by systems of partial differential equations (PDEs) in complex moving domains.High-resolution finite difference or finite volume methods are used on a collection of structured curvilinear grids. This basic differencing technol-ogy is combined with block-structured adaptive mesh refinement (AMR) to pro-vide local resolution in the computation with correspondingly greater computa-tional efficiency. At LawrenceLivermore National Laboratory (LLNL),this approach is used for high-resolution simulations of incompressible and low Mach number hydrodynamics flows in complex moving geometries. The pay-Figure 1.This simulation of a shock interacting with a cylindrical obstacle demonstrates the structured adaptive mesh refinement capabilities within Overture.The two component grids (shown in blue) are refined independently using a Berger-Oliger style approach.The two levels of refinement grids are indicated by the green and red patches.This work was performed under the auspices of the U.S. Department of Energy by University of California Lawrence Livermore National Laboratory under contract No. W -7405-Eng-48.OvertureOverture classes provide tools for the rapid development of application codes. The main class categories are listed below.1. A++/P++ arrays describe multidi-mensional arrays and provide for serial and parallel operations on those arrays. In the parallel environ-ment, these provide for thedistribution and interpretation ofcommunication required for thedata-parallel execution of operations on the arrays.2. Mappings define transformations such as curves, surfaces, areas, and volumes. These are used to represent the geometry of the computational domain.3. Grids define a discrete representationof a mapping or mappings. These include single grids and collections of grids, in particular composite overlapping grids. CASC’s Rapsodi project provides tools for the con-struction of curvilinear grids and for overlapping those grids to represent complex moving geometries.4. Grid functions provide for the repre-sentation and centering of solution values such as density, velocity, and pressure, defined at each point on the grid(s).5. Operators provide discrete represen-tations of differential operators and boundary conditions through finitedifference or finite volume approxi-mations.6. Visualization tools based on OpenGL are provided to furnish a high-level graphics interface for visualizing geometry and simulation results.7. Adaptive mesh refinement provides automatic refinement of the overlap-ping grid structure for increased local resolution and efficiency of computational simulations.8. Load-balancing tools are provided for automatic load-balancing of computations on the adaptive over-lapping grid structure on parallel computers.9. Parallel distribution mechanisms are provided through the PADRE library,part of the DOE 2000 ACTS toolkit.10.Full Fortran-like performance pro-vided by the ROSE optimizingsource-to-source code preprocessor.Overture Application Code DevelopmentScientists at LLNL collaborate with academia to use Overture to develop flow solvers for high-speed compress-ible flow problems, incompressible flow problems, low Mach number,non-Newtonian, and reacting fluid flow problems.Through its object-oriented design,Overture reduces code duplication,encourages interoperability of applica-tion software, and simplifies the learning curve for new computational methods.Overture’s object-oriented architecture provides flexibility to address a wide range of applications that involve simu-lations in complex moving geometry on serial and parallel computers. The advantages of this approach include reduced code development time and broader, more in-depth research into numerical methods for scientific and industrial applications.For additional information about Overture,contact David L.Brown,(925) 424-3557,dlb@;or William Henshaw,(925) 423-2697,henshaw@;orDaniel J.Quinlan,(925) 423-2668,dquinlan@./casc/Overture/Figure 3.The moving geometry capabilities of Overture are demonstrated in this figure.Here two solid drops interact with a viscous fluid under the force of gravity.The use of overlapping grids is an efficient approach for computing such flows since the grids do not have to be regenerated as the solution evolves.Only the locations of the interpolation points used to communicate information between the grids is recomputed at each time step,a much more efficient operation.Figure 2.Overlapping grids can be used to rep-resent complex geometries by combining component grids.This example uses compo-nent meshes provided by engineers atChalmers University of Technology,Sweden.。

uml的课件Chapter1 Introduction

7
Tianjin Technology University
4 Relations between Classes(类的关系) 一般具体结构关系和整体成员结构关系
分类结构 car 组装结构 car father class or superclass
is a ”或“关系 transportation
13
Tianjin Technology University
3 Inheritance(继承性)
(P2, par.2)
Inheritance is the sharing of attributes and operations among classes based on a hierarchical relationship. 继承性是父类和子类之间共享数据结构和方法的机制，这是类之间的一种关系。在定义一个和实现一个新类的时候，可以在一个已经存在的类的基础上来进行，把这个已经存在的类所定义的内容作为自己的内容，再加入若干新的内容。在这种层次关系中，子类只继承一个父类的数据结构和方法，称为单重继承；继承多个父类的，称为多重继承。
类：教师属性：姓 attribute 年单职工名龄位称资
abstract instance
对象：雷鸣状态：雷鸣保密 statБайду номын сангаас 计算机教授 €1w 行为：调工资 behavior 评职称受聘
数据结构
操作：调工资 behavior 评职称受聘
方法：调工资
(P1, par.4, 3 lines to bottom)
每个对象都有自身的唯一标识。在对象的整个生命周期中，它的标识都不变。在对象建立时，由系统授予新对象唯一的对象标识符。

ADMAT Automatic di#erentiation in MATLAB using object oriented methods #

ADMAT:Automatic diﬀerentiation in MATLAB using objectoriented methods∗Arun Verma†AbstractDiﬀerentiation is one of the fundamental problems in numerical mathematics.The solution of many optimization problems and other applications require knowledge ofthe gradient,the Jacobian matrix,or the Hessian matrix of a given function.Automatic diﬀerentiation(AD)is an upcoming powerful technology for computing the derivatives accurately and fast.ADMAT(Automatic Diﬀerentiation for MATLAB)implements AD using the object oriented technology in MATLAB[11]and can computederivatives of up to second order.ADMAT can be used as a plug-in tool for ADMIT-1[4]and ADMIT-2[5]toolboxes,enabling the computation of sparse and structuredderivative matrices for nonlinear optimization.1IntroductionNumerical solutions of large scale nonlinear problems involve computing derivative informa-tion in the form of gradients,Jacobian and Hessian matrices,often repeatedly,making the computation of derivatives a central part of the solution process.This makes it necessary to have an accurate and eﬃcient derivative computation for the practical solution of large nonlinear problems.Automatic diﬀerentiation can compute fast and exact1derivatives of any degree computationally via propagating Taylor series coeﬃcients using the chain rule[8].Although still in its formative stages,AD is now a very powerful tool(e.g.ADOL-C[9]and ADIFOR[1]are two popular AD tools)especially when coupled with recent developments, e.g.exploitation of the user problem structure[13,3,2].The traditional methods of obtaining derivatives such as hand-coding orﬁnite diﬀerencing suﬀer in comparison with AD;hand-coding is error-prone and can be impractical due to time requirements for the code development and maintenance whileﬁnite diﬀerencing often doesn’t yield accurate derivatives and may be ineﬃcient in many cases.ADMAT enables you to diﬀerentiate nonlinear maps deﬁned via M-ﬁles.To our knowledge this is theﬁrst AD tool written for diﬀerentiating M-ﬁles.ADMAT belongs to the“operator overloading”class of AD tools and uses the object oriented programming (OOPS)feature present in MATLAB5for its implementation.ADMAT can be used as a plug-in tool for the ADMIT-1toolbox[4],enabling the computation of sparse Jacobian and Hessian matrices of general nonlinear functions.Here is a simple ADMIT-1example which uses ADMAT for computing the sparse Jacobian of a simple test problem(myfun.m)which has an arrowhead Jacobian sparsity pattern: function y=myfun(x,Extra)y=x.∗x;y(1)=y(1)+x′∗x;y=y+x(1)∗x(1);endAssume this program is saved inﬁle myfun.m.To evaluate the function F and the Jacobian J at x′=(1,1,...,1)for n=5:>>x=ones(5,1);>>[f,J]=evalJ(’myfun’,x);As illustrated by this example,all the details of the plug-in AD tool(ADMAT here) are completely hidden from the the users of ADMIT-1making it a user friendly tool.This document is organized as follows.In§2,we present the basics of an AD tool based on overloaded methods.In§3we present the basics of doing AD of a MATLAB-like language.In§4,we present all the implementation details including the description of the derivative objects used in ADMAT.For more information about ADMAT,please refer to our website:/home/verma/AD/research.html.2Basics of a OOPS based AD toolAutomatic diﬀerentiation is a chain-rule-based technique for evaluating the derivatives with respect to the input variables of functions deﬁned by a high-level computer program.AD relies on the fact that all computer programs,no matter how complicated,use aﬁnite set of elementary(unary or binary,e.g.,sin(.),sqrt(.))operations as deﬁned by the programming language.The value or function computed by the program is simply a composition of these elementary functions.The partial derivatives of the elementary functions are known,and the overall derivatives are computed using the chain rule[8].Abstractly,the program to evaluate an output y(generally an m vector)as a function of x(generally an n vector)has the form:x≡(x1,x2,...,x n)↓z≡(z1,z2,...,z p)↓y≡(y1,y2,...,y n)where the intermediate variables z are related through a series of binary operators,z k=f k elem(z i,z j),i<k,j<k,p>>m+n.Automatic Diﬀerentiation has two basic modes of operations,the forward mode and the reverse mode.In the forward mode the derivatives are propagated throughout thefunction y=getfun(x)z=x∗x;z=x+z;y=z∗z;endFig. 1.A sample functioncomputation using the chain rule,e.g.for the elementary step z k=f k elem(z i,z j)the intermediate derivative,dz kdx =∂f k elemdx+∂f k elemdxIn the reverse mode the adjoint derivatives are propagated backwards:dy∂z idydz j =∂f k elemdz kAt the end of the computation using the reverse mode the desired derivative dy ∂z j,∂f k elemx = 2.0dx/dx = 1.0z= 4.0dz/dx = 2*x*dx/dx=4.0w = 6.0dw/dx=dx/dx+dz/dx = 5.0y= 36.0dy/dx=2*w*dw/dx = 60.0Fig. 2.Flowchart corresponding to the sample function inﬁgure13Diﬀerentiating Matrix Vector OperationsIn this section,we describe the rules ADMAT uses to diﬀerentiate high-level matrix vector operations in MATLAB.Diﬀerentiation carried out at the level of matrix-vector operations has a lot of advantages.It reduces the spatial complexity in the reverse mode,where only high-level objects like matrices and vectors need to be saved instead of all the intermediate scalar variables.To illustrate,consider the example of a dot product of two vectors:at the scalar-level it is coded using a“for”loop,function z=dotproduct(x,y)z=0;for i=1:nz=z+x(i)∗y(i);endendThis code generates n+1extra intermediate variables:an elementary AD tool will need to diﬀerentiate through all intermediate variables.However,as we illustrate in this chapter,the AD at the matrix-vector level doesn’t need to take these intermediate variables into account.The dot product savings made aren’t much,but if you consider the example of a matrix-matrix product,the number of intermediate variables generated are n3,while the size of the objects involved in the operation is n2,which can seriously degrade the performance of the reverse mode in the elementary AD mode.The gains become more pronounced for implicit matrix-vector operations,e.g.the solution of a linear system, y=A\x,where the number of intermediates generated is quite large.A lot of discussion on this subject and more details on high-level diﬀerentiation can be found in the work done by Coleman&Verma and the Ph.D thesis of the author [6,3,2,13].There are other insights gained by this high-level view,rmation about parallelization of derivative code.Some related work in vector diﬀerentiation is included in the Ph.D.thesis by Dmitri Shiriaev[12].3.1Forward modeIn the forward mode ADMAT overloads all the elementary functions(MATLAB built-in functions in this case,e.g.exp,sum,+,-etc.),to not only compute the“value”of the output,but also update“derivatives”of the output consistently using the chain rule to propagate aylor series coeﬃcients.In Table1we present a listing of how we handle some of the matrix-vector operations. Here we present rules for propagation of derivatives in one tangential direction;it is trivial to extend them to include multiple tangential directions(indeed ADMAT implements derivative computation in arbitrary number of tangential or adjoint directions).The notation˙z corresponds to the forward product∂zTangent Rule˙z=y T˙x+x T˙yz=x+y˙z=˙x.∗y+˙y.∗xy=A∗x˙y=A\(˙x−˙Ay)C=A+B˙C=˙A∗B+A∗˙BThe tangent propagation rules are easy to derive using the chain rule.The rules for the implicit matrix-vector operations can be a little tricky,e.g.,the“solve”operation:y=A\x. Let us illustrate the derivation of the tangent rule by expressing the solve operation as:Ay=x.Diﬀerentiating w.r.t.a scalar input variable IA˙y+˙Ay=˙xor˙y=A\(˙x−˙Ay).which corresponds to the rule in Table1.3.2Reverse modeIn Table2we present a listing of rules for the computation of adjoints for some of the matrix vector operations.z∗corresponds to the adjoint product∂OTable 2Adjoint propagation rulesOperationz =x T yx ∗=z ∗,y ∗=z ∗z =x.∗yx ∗=A T ∗y ∗,A ∗=(y ∗)x T y =A \xA ∗=C ∗,B ∗=C ∗C =A ∗B Sparsity pattern RuleJ z = J x (i )+J y (i )z =x +yJ z =J x +J yy =AxJ C =J A +J BC =A ∗BJ C =J A +J BHessian sparsity patterns (2nd order derivatives).Hence we need chain rule propagation from 2nd order Taylor series.We omit the details of the propagation rules involved and refer the interested reader to [13].4Functionality of ADMATAs we have seen in previous sections,ADMAT has both reverse and forward mode capability and can compute derivatives up to second order.In summary,ADMAT provides the following ﬁve functions:1.Vector valued functions :(a)Jacobian-Matrix (forward)product .(F,x,V )→J (x )V .(b)Matrix-Jacobian (reverse)product .(F,x,W )→J (x )T W .(c)Jacobian Sparsity Pattern .F →SP J .2.Scalar valued functions :(a)Hessian-Matrix product .(f,x,V )→H (x )V .(b)Hessian Sparsity Pattern .f →SP H .The above functionality allows ADMAT to be used as a plug-in tool for ADMIT-1,enabling computation of sparse Jacobians and Hessians of target M-ﬁles,and with ADMIT-2,allowing the computation of derivatives of structured computations.ADMAT can also be plugged-into the MATLAB optimization toolbox,currently in beta-release.5Implementation of derivative classes in ADMATADMAT is designed as a three-layer toolbox as shown in ﬁgure 3,with the top layers inheriting from the bottom layers.The core of the ADMAT toolbox is the class deriv ,which is the basic forward mode computing engine of ADMAT.The layer above deriv contains two classes,namely,derivtape ,the basic reverse mode computing engine of ADMAT,and derivspj ,the Jacobian sparsity pattern computing engine of ADMAT.The topmost layer which is concerned the computation of second order derivatives consists of two classes,derivtapeH for computing Hessian vector products and derivsph for computing sparsity pattern of Hessians.derivderivtapeH derivtape derivsphderivspjFig. 3.Design of ADMAT toolbox5.1Class derivderiv is an extension of double (MATLAB ﬂoating point numbers belong to class double ).A deriv object has two ﬁelds,val and deriv ,which stand for the value of the variable and the derivative respectively.For a deriv object x ,x.val is the value of x ,and x.deriv represents the derivative ˙x w.r.t.given independent variables.In the “AD-mode”the function computation is carried out with deriv variables causing all the operations to be used in the “overloaded”mode thus invoking the rules in 1which update the derivative of the output along with the value.The deriv constructor can be used in the following two diﬀerent ways:•y=deriv(x)Constructs a deriv object y from a double variable x .y has the value of x with the derivative ﬁeld set to zero.•y=deriv(x,V)Constructs a deriv object y with the given derivative (or tangent direction)V .This is typically used for setting up the independent variables.Here is the code for the constructor:function s =deriv (a,V )s.val =a ;if nargin ==1s.deriv =zeros (size (a ));elses.deriv =V ;ends =class (s,′deriv ′);endfunction sout=plus(s1,s2) sout.val=s1.val+s2.val;; sout.deriv=s1.deriv+s2.deriv; sout=class(sout,′deriv′);end function sout=times(s1,s2)sout.val=s1.val.∗s2.val;;sout.deriv=s1.deriv.∗s2.val+s1.val.∗s2.deriv; sout=class(sout,′deriv′);endFig. 4.deriv Method for addition&point-wise multiplication Figure4shows the addition and pointwise multiplication methods for deriv class.For a given nonlinear map F(x):ℜn→ℜm,deriv class can be used to compute the Jacobian-Matrix product JV=dydx .We need to pass the inputargument x as derivtape object,and run a reverse pass on the tape with the initial adjoint W.The required adjoint W T dyNodenum = 1op = ’assign’val = 2.0arglist = []Nodenum = 2op = ’times’val = 4.0arglist = [1,1]Nodenum = 3op = ’plus’val = 6.0arglist = [1,2]Nodenum = 4op = ’times’val= 36.0arglist = [3,3]Fig. 5.tape corresponding to the sample function inﬁgure1A derivspj object has twoﬁelds value and deriv which contain the value and the sparsity pattern of the derivative respectively.The derivsph class which inherits from derivspj,has an extraﬁeld derivsph which contains the sparsity pattern for the second derivative.6Diﬀerentiating complicated MATLAB functionsThe methods of deriv class(also derivtape and other classes in ADMAT)code the rule to diﬀerentiate a particular MATLAB function.There are two ways of diﬀerentiating complex MATLAB builtin functions.One way is to useﬁnite diﬀerencing for functions for which the exact math is not known,and the other is to use analytical(hand-coded)diﬀerentiation for functions for which the math and hence the diﬀerentiation rules are known.Many functions do not allow analytic diﬀerentiation.For example,LU factorization and QR factorizations are implemented using MEXﬁles in MATLAB,henceﬁnite diﬀerencing has to be used to get derivatives.If analytical derivatives are required they can be obtained by writing a M-ﬁle for LU factorization and diﬀerentiating through it,but that might be ineﬃcient.Diﬀerentiation of the eigenvalue solver requires extra information to be coded analytically(e.g.,to compute the derivative of an eigenvalue w.r.t.a parameter on which the matrix depends on,the eigenvector information is required too).If this information is available analytical diﬀerentiation is carried out otherwiseﬁnite diﬀerencing is used.All the simple functions in MATLAB are implemented in ADMAT using analytical diﬀerentiation e.g.sin,cos,sum,min,max,exp etc.For these functions it is trivial to code the diﬀerentiation rule.ADMAT also allows derivatives of sparse objects,i.e.,the derivatives are propagated as sparse matrices and sparsity is preserved wherever possible. 7Concluding RemarksThe development of AD technology via object oriented methods for a high-level language like MATLAB provides a variety of beneﬁts,including:•The resulting AD tool is highly extendible.This is one of the advantages of using the object oriented technology.The AD tool can be trivially extended to diﬀerentiate any matrix-vector operation,e.g.your favorite eigenvalue solver or a matrix factorization method.•The AD tool is portable.Since the AD tool is written in MATLAB,it can be used just like any MATLAB function/toolbox.There are no compilation steps needed to use this tool(unlike AD tools which diﬀerentiate Fortran or C programs).Also, ADMAT can be readily applied to any of the thousands of diﬀerent functions present in MATLAB toolbox.•The diﬀerentiation carried out at the matrix-vector level is very eﬃcient in both space and time,compared to the traditional scalar-level AD.In summary,the ADMAT toolbox extends the MATLAB environment to provide a powerful computing environment for large-scale optimization and sensitivity analysis. The capability of doing automatic diﬀerentiation of MATLAB opens up a wide range of applications which can use the AD technology in a much easier and quicker manner.With ADMAT,it is now possible to diﬀerentiate through a variety of MATLAB toolboxes,thus enabling AD of complicated MATLAB applications.References[1]C.H.Bischof,A.Carle,G.F.Corliss,A.Griewank,and P.Hovland,ADIFOR:Generatingderivative code from FORTRAN programs,Scientiﬁc Programming,1(1992),pp.11–29. [2]T.F.Coleman and A.Verma,Structure and eﬃcient Hessian calculation,in Advances inNonlinear programming,proceedings of96International conference on nonlinear programming, Y.xiang Yuan,ed.,Kluwer Academic Publishers,Boston/Dordrecht/London,1996,pp.57–72.[3],ADMIT-1:Automatic diﬀerentiation and matlab interface toolbox,submitted to ACM TOMS,(1998).[5],The eﬃcient computation of sparse Jacobian matrices using automatic diﬀerentiation, SIAM Journal on Scientiﬁc Computing,19(1998),pp.1210–1233.[7]A.Griewank,Achieving logarithmic growth of temporal and spatial complexity in reverseautomatic diﬀerentiation,Optimization Methods and Software,1(1992),pp.35–54.[8]。

Object Orientation

Object Orientation1.Abstraction抽象Ways to simplify complex practical problems, it can find the most appropriate for specific problems of the class definition, and can be inherited in the most appropriate levelexplain the problem简化复杂的现实问题的途径，它可以为具体问题找到最恰当的类定义，并且可以在最恰当的继承级别解释问题2.Encapsulation包装In order to achieve a wide variety of data transmission, data will be transmitted structure mapping into another data structure为实现各式各样的数据传送，将被传送的数据结构映射进另一种数据结构的处理方式3.Modularity模块化The breaking up of something complex into manageable pieces打破一些复杂的东西分成几部分4.Hierarchy层次Elements at the same level of the hierarchy should be at the same level of abstraction.元素在同一层级的级别应该是在同一层次的抽象Basic Concepts of Object Orientation♦ObjectAn object is a concept, abstraction, or thing with sharp boundaries and meaning for anapplicationAn object is something that has:1) State2) Behavior3) Identity♦ClassA class is a description of a group of objects with common properties (attributes),behavior (operations), relationships, and semanticsAn object is an instance of a classA class is an abstraction in that it:Emphasizes relevant characteristicsSuppresses other characteristicsA class is represented using a compartmented rectangle一个类是一个描述一组对象的共同属性(属性)、行为(操作)、关系和语义一个对象是一个类的实例一个类是一个抽象概念,它:强调相关特征抑制其他特征一个类是使用隔离矩形表示A class is comprised of three sectionsThe first section contains the class nameThe second section shows the structure (attributes)The third section shows the behavior (operations)一个类是由三个部分第一个部分包含类名称第二部分给出了结构(属性)第三部分给出了行为(操作)The Relationship between Classes and ObjectsA class is an abstract definition of an objectIt defines the structure and behavior of each object in the classIt serves as a template for creating objectsObjects are grouped into classes一个类是一个抽象对象的定义它定义了每个对象的结构和行为的类它作为一个模板来创建对象对象被分成类♦Attribute♦Operation♦Interface (Polymorphism)The ability to hide many different implementations behind a single interface有能力在一个接口后面隐藏许多不同的安装Interfaces formalize polymorphism接口使多态性更正式化Interfaces support “plug-and-play” architectures接口支持一种不必经由用户复杂安装即可使用的软件，即插即用的架构♦Component♦Package♦Subsystem♦RelationshipsAssociation关联，联合Models a semantic connection among classes模型类间语义关系Aggregation聚合A special form of association that models a whole-part relationship between anaggregate (the whole) and its parts一种特殊形式的协会,模型一个整体部分关系聚合(整个)及其零部件Composition成分A form of aggregation with strong ownership and coincident lifetimesThe parts cannot survive the whole/aggregate一种聚合与强壮的所有权和一致的一生零件无法生存的整个/聚合Dependency依赖A relationship between two model elements where a change in one may cause a change in the otherNon-structural, “using” relationship两个模型元素之间的关系,改变一个可能导致改变其他非结构性,“使用”关系Generalization泛化A relationship among classes where one class shares the structure and/or behavior of one or more classesDefines a hierarchy of abstractions in which a subclass inherits from one or more superclasses Single inheritanceMultiple inheritanceGeneralization is an “is-a-kind of” relationship一个类一个类之间的关系,股票的结构和/或行为的一个或多个类定义了一个抽象的层次,一个子类继承自一个或多个超类单继承多重继承泛化是一个”是一种“关系的Realization实现Lifecycle PhasesInception→ Elaboration → Construction →TransitionInception: Define the scope of the project and develop business case.起初：定义项目的范围和开发业务案例Elaboration: Plan project, specify features, and baseline the architecture. 细化：计划项目,指定功能,和基线架构。

面向对象领域建模研究

面向对象领域建模研究第一章研究背景随着计算机技术和软件开发的不断发展，软件的复杂度也越来越高。

而面向对象编程（Object-Oriented Programming，简称OOP）所提供的封装、继承、多态等特性，已经成为了现代软件开发的基础。

在面向对象编程的基础上，面向对象领域建模（Object-Oriented Domain Modeling，简称OODM）就显得尤为重要。

OODM是面向对象编程的前提和基础。

它是指将现实世界中的事物和概念，通过面向对象的方式，转化为计算机程序中的对象、类、属性和方法等概念。

通过OODM，开发人员可以更好地理解客户需求，并且可以使软件开发更加高效和可靠。

本文主要研究在软件开发中应该如何进行OODM，以及如何构建一个高质量的OODM。

第二章 OODM的基本概念2.1 对象对象是现实世界中的事物和概念在程序中的体现。

它包含了数据和对数据的处理方法。

举个例子，一个人可以作为一个对象，它的数据包括姓名、年龄、性别等属性，它的处理方法包括吃饭、睡觉、工作等行为。

2.2 类类是一组具有相同属性和行为的对象的模板。

它定义了对象的结构和行为。

在类的定义中，我们可以定义成员变量和成员函数。

成员变量表示对象的属性，而成员函数表示对象的行为。

举个例子，人类这个概念可以作为一个类，它的成员变量包括姓名、年龄、性别等属性，它的成员函数包括吃饭、睡觉、工作等行为。

2.3 属性属性是对象的特征。

它们是描述对象的数据或状态。

一个对象可以有多个属性。

例如，一个人可以有姓名、年龄、性别等属性。

2.4 方法方法是对象的行为。

它们是对象能够执行的操作。

方法可以被其他对象调用，以便执行某种功能。

例如，一个人可以有吃饭、睡觉、工作等方法。

2.5 继承继承是一种重要的面向对象编程特性，它表示一个类可以派生出其他类。

继承使得派生的类可以继承父类的所有成员变量和成员函数。

这样，派生类就可以在父类的基础上添加或修改一些属性和行为。

java英文面试题

java英文面试题Java English Interview QuestionsIntroduction:In today's competitive job market, English interviews for Java developers have become increasingly common. It is important for candidates to be well-prepared and confident in their English language skills. In this article, we will explore some common Java interview questions that may be asked in an English interview format.1. Can you explain the concept of object-oriented programming (OOP)?Object-oriented programming (OOP) is a programming paradigm that revolves around the concept of objects, which can contain both data and behavior. It allows developers to create modular and reusable code by defining classes, objects, and their relationships. In Java, OOP is achieved through features like classes, objects, inheritance, polymorphism, and encapsulation.2. What are the differences between an abstract class and an interface?In Java, both abstract classes and interfaces are used to achieve abstraction and define common behavior. However, there are some differences between them.- An abstract class can have both abstract and non-abstract methods, while an interface can only have abstract methods.- A class can inherit from only one abstract class, but it can implement multiple interfaces.- An abstract class can have instance variables, but interfaces cannot.- An abstract class provides the flexibility to define default implementations, whereas interfaces do not.3. How do you handle exceptions in Java?Exceptions are used to handle unexpected or exceptional situations in Java. The try-catch block is used to catch and handle exceptions. The try block contains the code that may throw an exception, and the catch block handles the exception that is caught. Additionally, there is a finally block that is executed regardless of whether an exception is caught or not. It is used for cleanup tasks such as closing the resources.4. Explain the differences between a checked exception and an unchecked exception.In Java, checked exceptions are checked at compile-time, meaning the compiler forces the developer to handle or declare these exceptions. Examples of checked exceptions include IOException and SQLException. On the other hand, unchecked exceptions are not checked at compile-time and do not need to be declared or caught explicitly. Unchecked exceptions are subclasses of RuntimeException and include exceptions like NullPointerException or ArrayIndexOutOfBoundsException.5. What is the difference between the "==" operator and the "equals()" method?In Java, the "==" operator is used to compare if two objects or primitive data types have the same value. It checks for reference equality when used with objects. On the other hand, the "equals()" method is used to comparethe contents or values of objects. It is defined in the Object class and can be overridden by subclasses to provide custom comparison logic.6. Can you explain the concept of multithreading in Java?Multithreading is the ability of a program to simultaneously execute multiple threads of execution. A thread is a lightweight sub-process that can run concurrently with other threads in a program. In Java, multithreading can be achieved by extending the Thread class or implementing the Runnable interface. Multithreading is useful for improving performance, utilizing multiple CPU cores, and managing concurrent operations.Conclusion:In this article, we discussed several common Java interview questions that may be asked in an English interview format. It is essential for Java developers to have a good understanding of concepts such as object-oriented programming, exception handling, and multithreading. By preparing and familiarizing themselves with these topics, candidates will be better equipped to navigate the Java English interview successfully. Remember, practice and continuous learning are key to mastering Java and succeeding in interviews.。