Showing papers by "Grady Booch published in 1993"

Object-oriented analysis and design with applications (2nd ed.)

Abstract: I. CONCEPTS. 1. Complexity. The Inherent Complexity of Software. The Structure of Complex Systems. Bringing Order to Chaos. On Designing Complex Systems. Sidebar: Categories of Analysis and Design Methods. 2. The Object Model. The Evolution of the Object Model. Elements of the Object Model. Applying the Object Model. Sidebar: Foundations of the Object Model. 3. Classes and Objects. The Nature of an Object. Relationships Among Objects. The Nature of a Class. Relationships Among Classes. The Interplay of Classes and Objects. On Building Quality Classes and Objects. Sidebar: Invoking a Method. 4. Classification. The Importance of Proper Classification. Identifying Classes and Objects. Key Abstractions and Mechanisms. Sidebar: A Problem of Classification. II. THE METHOD. 5 .The Notation. Elements of the Notation. Class Diagrams. State Transition Diagrams. Object Diagrams. Interaction Diagrams. Module Diagrams. Process Diagrams. Applying the Notation. 6 .The Process. First Principles. The Micro Development Process. The Macro Development Process. 7. Pragmatics. Management and Planning. Staffing. Release Management. Reuse. Quality Assurance and Metrics. Documentation. Tools. Special Topics. The Benefits and Risks of Object-Oriented Development. III. APPLICATIONS. 8. Data Acquisition: Weather Monitoring Station. Analysis. Design. Evolution. Maintenance. Sidebar: Weather Monitorint Station Requirements. 9. Frameworks: Foundation Class Library. Analysis. Design. Evolution. Maintenance. Sidebar: Foundation Class Library Requirements. 10. Client/Server Computing: Inventory Tracking. Analysis. Design. Evolution. Maintenance. Sidebar: Inventory Tracking System Requirements. 11. Artificial Intelligence Cryptanalysis. Analysis. Design. Evolution. Maintenance. Sidebar: Cryptanalysis Requirements. 12. Command and Control Traffic Management. Analysis. Design. Evolution. Maintenance. Sidebar: Traffic Management System Requirements. Afterword. Appendix: Object-Oriented Programming Languages. A.1 Concepts. A.2 Smalltalk. A.3 Object Pascal. A.4 C++. A.5 Common Lisp Object System. A.6 Ada. A.7 Eiffel. A.8 Other Object-Oriented Programming Languages. Notes. Glossary. Classified Bibliography. A. Classification. B. Object-Oriented Analysis. C. Object-Oriented Applications. D. Object-Oriented Architectures. E. Object Oriented Databases. F. Object-Oriented Design. G. Object-Oriented Programming. H. Software Engineering. I. Special References. J. Theory. K. Tools and Environments. Index. 0805353402T04062001

How to get a paper accepted at OOPSLA (panel)

Abstract: The last few OOPSLA’s have had acceptance ra.tes of around 12by anyone’s standards. The a.ccepta,nce ra,te for OOPSLA’93 wa.s Sdue in pa,rt to a. large number of submissions, a.nd in part to a program committee with very high standards. But it is also due to a ra.pidly growing community that does not all understood the standards. Although the set, of standa.rds is not widely understood, there is a, set of standaads. There a.re many a.rea,s of disa.greement., but they are outweighed by the area.s of a.greement. The purpose of this pa.nel is to try to explain how OOPSLA papers a.re judged so that, it will increa.se the odds that your paper will be accepted. Alan Snyder’s appendix to the OOPSLA’91 proceedings on “How to get a. paper accepted at OOPSLA” is very a.ccura.te. However, abstract rules like “explain the contribution of your pa.per” and “convince the pr0gra.m committee tl1a.t your work is correct” can be interpreted differently for different kinds of papers. That is why most of the panel members will describe the way that sta.ndards are applied to a particular topic. Kent Beck will give his extremely concret,e rules for writing papers. One piece of a,dvice tha,t often seems t,o be ignored is to have your paper reviewed by collea.gues. Two of the most important rules are that. papers should be understandable and that they should be of interest to the OOPSLA community. In both these cases, you will need outside readers to tell whether t.he paper is acceptable. I have a hard time telling whether a paper I wrote is easy to understand I never have any trouble understanding my papers. Most people are like me. Since most a.uthors are new to the OOPSLA community, they have a hard time telling whether the paper is of interest. Many problems can be avoided by having someone else read your paper and criticize it. The best reviewers will be people who are active in the area and who often attend OOPSLA, but who are from a. different institution and so do not know the work yowl a,re report.ing on. Authors of pa.pers you are citing are good prospects, especially if the pa.pers were presented at OOPSLA. They can tell you whether you are ignoring some related work and whether they are convinced by your argument.