From: CRDGW2::CRDGW2::MRGATE::"SMTP::MWSUN.MITRE.ORG::NIGAM" Date: 6-SEP-1989 18:24:36 Description: Software Engineering Digest v6n48 Return-Path: Received: by mwsun.mitre.org (5.54/SMI-2.2) id AA22812; Wed, 6 Sep 89 17:17:20 EDT Date: Wed, 6 Sep 89 17:17:20 EDT From: nigam@mwsun.mitre.org (Alok Nigam) Message-Id: <8909062117.AA22812@mwsun.mitre.org> Organization: The MITRE Corp., Washington, D.C. To: soft-eng-dist@mwunix.mitre.org Subject: Software Engineering Digest v6n48 Software Engineering Digest Wed, 6 Sep 89 Volume 6 : Issue 48 Today's Topics: Attempts to connect SA/D and OOPS Mass Acknowledgement: Votes for comp.object More Object-Oriented Metrics References Software Reliability Research ---------------------------------------------------------------------- Date: 5 Sep 89 19:20:51 GMT From: Edward Berard Subject: Attempts to connect SA/D and OOPS In article , Dick Botting writes: > In Vol 6 Number 42, Edward Berard described > the costs and problems of discarding older methods and tools to gain the > benefits of Object Oriented Programming. He mentions 4 new methods: > > OODA - Object-oriented domain analysis > OORA - Object-oriented requirements analysis > OOD - Object-oriented Design > OOP - Object-oriented implementation > (often called Object-oriented programming) > > He stated that these were different to previous methodologies and hinted > at the existence of much detailed information on these techniques. He > also said that > >I would very much like to avoid a detailed discussion of the processes > >involved in OORA, OOD and OODA > > I would certainly value a detailed discussion of such topics - > a seminar on Ada and OOP costs $500 for example and 2 days. At present, I cannot go into a detailed discussion of the methodologies, but I can give you a sketch of the motivations, concepts, and backgrounds. Historically, much of the work in object-oriented technology focused on programming language issues, e.g., how to implement a particular concept in programming language X. Little thought was given to "formal approaches." In fact, a common description of object-oriented programming was: 1. create classes 2. create instances of the classes (i.e., objects) 3. cause the objects to interact via message passing. This approach works very well with small, easily-understood systems. However, as the size of a system grows, additional techniques are needed to manage the complexity. Make no mistake about it, object-oriented programming has made several important contributions to software engineering, _over_ _and_ _above_ _the_ _usually_ _cited_ _advantages_ _of_ _object-oriented_ _technology_, e.g.: - The concepts and techniques of "composition" as opposed to "decomposition." Traditional approaches, emphasized breaking a system down until all that remained were easily understood units (modules). While this did help to manage one type of complexity, it did little to offset the increased complexities of duplications, and "re-invention of the wheel." Many people confuse composition techniques with "code first, think later." This is not the case. Composition dictates that the developers have a library of reusable components, and that at some point during development, the software engineers will be able to make an informed decision as to which, if any, of these components can be used in the new system. - The concept of treating vastly dissimilar items in a similar manner, thus keeping things simple. For example, a graphics object can be stored and retrieved in much the same manner as a text object. (It is no accident that polymorphism is very often associated with object-oriented approaches.) You might say that object-oriented software engineering involves: - the identification of relevant objects and classes - documentation of these items - the application of sound configuration management to the objects and classes - documenting the interaction of these items with each other and their surroundings in a manner which is consistent with an object-oriented philosophy. - application of testing, maintenance, quality assurance, debugging, and other techniques in a manner consistent with an object-oriented philosophy. Note that I carefully avoided saying how the "relevant objects and classes" were identified, e.g., they could have been identified by inspection, or uncovered via decomposition of a large system. Of course, we should point out that object-oriented approaches are fundamentally different from the more traditional approaches. Further, we should also observe that the general life-cycle approach is very different, i.e., object-oriented life-cycles are recursive/parallel ("analyze a little, design a little, implement a little, test a little"), as opposed to the more traditional waterfall life-cycle (all the analysis, followed by all the design, followed by all the coding, etc.). If you will grant me that this is a "short net message" and not a series of week-long tutorials, I will attempt to present some material here regarding object-oriented life-cycle methodologies. Please remember that this is material taken out of context, and is presented with virtually no explanations. Object-Oriented Domain Analysis (OODA) may be accomplished by: 1. Defining the domain 2. Defining (conceptually) the object-oriented items which are to be considered for reuse within the domain 3. Collection of a representative sample of applications found within the application domain 4. Analysis of these representative applications it identify reusable components 5. Defining reusability guidelines regarding the reusable components 6. Demonstrating reuse using the reusable components and the guidelines 7. Making recommendations [OODA can be, and is, much more formal than these few points suggest.] Object-oriented requirements analysis (OORA) can be accomplished by: 1. Identifying the sources of requirements information 2. Characterizing the sources of requirements information [Note that these first two steps are required for any requirements analysis -- object-oriented, or not.] 3. Identifying candidate objects, classes, systems of objects, and subsystems (see my earlier postings on comp.lang.smalltalk for definitions of "subsystems" and "systems of objects") 4. Building object-oriented models of both the problem and potential solutions, as necessary 5. Re-localization of the information around the appropriate candidate objects, classes, systems of objects, and subsystems 6. The selection, creation, and verification of object and class specifications (OCSs), subsystem specifications, and system of objects specifications. 7. Assigning the above items to their appropriate place in the object-oriented requirements specification (OORS), i.e., the object-general section, or the application-specific section 8. The development and refinement of the qualifications section of the OORS 9. The development and refinement of the precise and concise system description. Object-oriented design (OOD) may be accomplished by: 0. Object-oriented domain analysis (OODA) 1. Object-oriented requirements analysis (OORA) 2. Identifying design objects and classes of interest 2.1 Developing a design strategy [at an appropriate level of abstraction] 2.2 Identifying objects, classes, subsystems, and systems of objects, of interest 2.3 Associating attributes with these items 3. Identifying operations suffered by and required of each object and class of interest 3.1 Identifying operations of interest 3.2 Associating attributes with the operations of interest 3.3 Handling composite operations 3.3.1 Decomposition into primitive operations 3.3.2 Decoupling of objects and classes 4. Selecting, creating, and verifying object and class specifications (OCSs), subsystem specifications, and systems of objects specifications, for design 4.1 Binding objects, classes, and operations 4.2 Examining objects and classes for completeness 5. Deciding on language implementations for objects, classes, systems of objects, and subsystems 5.1 Items identified during analysis 5.2 Items identified during design 6. Graphically representing both object-oriented items and their interactions 6.1 Static representations 6.1.1 Booch diagrams (can be used with many different languages) 6.1.2 Semantic networks 6.1.3 Subsystem graphics 6.1.4 Systems of objects graphics 6.2 Dynamic representations 6.2.1 State transition diagrams 6.2.2 Petri net graphs 6.2.3 Object-Message diagrams 7. Establishing the interface for each object-oriented item 7.1 Objects and classes 7.2 Systems of objects 7.3 Subsystems 8. Implementing each object-oriented item 8.1 Implementation of the interface objects and classes 8.2 Implementation of the other objects and classes 8.3 Recursive application of the object-oriented development process > He refers to the use of Petri Nets to describe the behaviors of > object-oriented systems - I studied these in some faculty seminars back in > the early 1970's - as I recall, when we drew a Petri Nets some of the cycles > in the equivalent directed graph were associated with `objects`. For example > Making coffee had cycles running thru all places involving `perculator`, > and another cycle covered all the `cup` occrrences and so on... When two or > more of these cycles overlapped then the objects tended to be interacting. > > Does something like this also happen in OO systems? Somewhat, however, it is more common to ask questions such as "what objects have to be in what states for a transition to occur?" Remember, in object-oriented Petri nets, places represent specific objects in specific states. > How many real projects have used Petri Nets? The Europeans in general, and the Italians especially, seem to be very interested in Petri nets and Petri net graphs. I know of a few communications systems applications which have made use of Petri net graphs. Although they are conceptually very simple, one of the biggest obstacles to their effective use is the apparent lack of understanding of how to use both levels of abstraction and equivalence classes to simplify models created using them. > How do you communicate a Petri Net over the network? One of the things I find particularly attractive about Petri net graphs is that they can be reduced to mathematical expressions. These mathematical representations have two very important additional benefits: they aid in the verification and automation of Petri net graphs, and once in their mathematical form, they can be converted to other representation forms, e.g., state transition diagrams. There is, of course, much more that I could say. Unfortunately, my time is limited. Thanks for listening. ------------------------------ Date: 4 Sep 89 21:21:50 GMT From: Edward Berard Subject: Mass Acknowledgement: Votes for comp.object According to the rules: > It is permitted to post a "mass acknowledgement" in which all the names > of those from whom votes have been received are posted, as long as no > indication is made of which way anybody voted until the voting period > is officially over. Since I have received almost 500 votes, and since many of my attempted replies have bounced, I am posting this "mass acknowledgement." If you do not see your net address here (I have sorted them), then I have not received your vote. If you would still like me to attempt to send you an individual acknowledgement, send me e-mail (eberard@ajpo.sei.cmu.edu), or phone (301-353-9652). -------------------------------------------------------------- A List of All Votes Received For the Formation of Comp.Object (As Of September 4, 1989) [Total Votes Received = 490] [This list was deleted because of its length and because it is of little interest to many non-usenet subscribers. I can send out copies on request. Alok] ------------------------------ Date: 2 Sep 89 18:39:31 GMT From: Edward Berard Subject: More Object-Oriented Metrics References A while ago, I posted the results of "the search for object-oriented metrics." Since then, I have both had requests for more information, and have become aware of new sources. What follows are some additional references. ----------------------------------- >From my own personal (Edward V. Berard) experience: At my former company (EVB Software Engineering, Inc.), when we began to design a series of reusable, object-oriented components, we wondered if there was a practical upper limit to the number of operations in the interface to a class. Based on conversations with Grady Booch, and on our own experience, we were able to say that: - most classes should have 20, or fewer, operations in their interfaces, with 24 operations being a practical upper limit. This does not mean that you cannot have a class with more than 24 operations in its interface. It just means that classes this size, or larger, will be exceptional, i.e., typically much less than 10% of the total number of classes in a class library. - most methods are very small, e.g., very few methods had more than 40 executable statements, and many involved only 1-3 executable statements. -------------------------- I have received some correspondence from Brian Nixon at the Department of Computer Science, University of Toronto, Ontario, Canada M5S 1A4 (nixon@ai.toronto.edu). Nixon is doing some work with "performance theory for semantic data model implementations." I have not yet finished reading all of the technical reports he has sent me, bu they look interesting. -------------------------- Here is an excerpt from a larger article ("Readings in Object-Oriented Technology") I wrote: Object-Oriented Metrics As organizations begin shifting to object-oriented approaches, they find that some of the ways in which they used to measure things are less appropriate. People have already begun asking about object-oriented metrics. Although most work in this area is relatively new, there are a growing number of references, including: [Duhl and Damon, 1988]. J. Duhl and C. Damon, "A Performance Comparison of Object and Relational Databases Using the Sun Benchmark," OOPSLA '88 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No. 11, November 1988, pp. 153 - 163. [Hufnagel and Brown, 1989]. S.P. Hufnagel and J.C. Brown, "Performance Properties of Vertically Partitioned Object-Oriented Systems," IEEE Transactions on Software Engineering, Vol. 15, No. 8, August 1989, pp. 935 - 946. [Liberherr and Holland, 1989]. K.J. Liberherr and I.M. Holland, "Assuring Good Style for Object-Oriented Programs," IEEE Software, Vol. 6, No. 5, September 1989, pp. 38 - 48. [Liberherr and Riel, 1988]. K.J. Liberherr and A.J. Riel, "Demeter: a CASE Study of Software Growth Through Parameterized Classes, "Journal of Object-Oriented Programming, Vol. 1, No. 3, August/September 1988, pp. 8 - 22. ------------------------------ Date: 5 Sep 89 13:43:40 GMT From: "james.m.keables" Subject: Software Reliability Research Project Failure and Fault Data Required for Important Software Reliability Research Some important current software reliability research is directed toward trying to predict software reliability for systems not yet built. There are several challenging problems that must be solved to do this, but results so far are promising. You can contribute to this effort and gain the satisfaction of participating in a potentially important advance in the field by collecting data to help solve one of the key problems. We need the following information on each of many projects: 1. Failure intensity with respect to execution time that would be experienced in operation if the program were released at the start of system test. If execution time can't be measured, we can use a quantity that is proportional to it, provided the constant of proportionality is known. A. This would be best obtained from load testing without correcting faults and with runs made at frequencies corresponding to the operational profile. We can accept either measured failure intensity (failures/CPU hr) or raw failure data (time intervals between failures or failures per time interval.) In the latter case we will compute the failure intensity. B. A second choice is failure data obtained from testing without repeating runs and with faults being corrected. Here, we will have to adjust the data to obtain the operational failure intensity. We can accept raw failure data in two formats: time intervals between failures or failures per time interval. 2. Average instruction execution rate in object instructions per second. 3. Program size in object instructions. 4. The number of faults remaining in the software at the start of system test. We will approximate this quantity from faults uncovered during system test, or preferably, faults uncovered during system test plus some period of operational use. If faults are introduced due to code that is added or modified after the start of system test, these faults should not be counted. If they can't be identified, we need to know the number of source lines added/modified after the start of system test and the total number of source lines at the start of system test, so we can compensate for them. 5. Information about the structure of the program (optional): A. Average (taken over all possible runs) number of executions/instruction for a run and average (taken over execution time) number of parallel paths through the program. B. A second choice is access to the source code. We need a contact who knows the project and the data taken and can interpret the data to us, answer questions, etc. Similarly, we will be happy to clarify the foregoing requests and help interpret them in the light of data that is available. The identity of all participating projects will be held in strict confidence. If you are interested in participating in this research, please contact one of the following people: Dr. Anneliese von Mayrhauser -or- James Keables Illinois Institute of Technology AT&T Bell Laboratories Department of Computer Science 1100 E. Warrenville Rd. 10 West 31st Street Naperville, IL 60566 Stuart Building Rm. 236 (312) 979-1045 Chicago, IL 60616 (312) 567-5256 ------------------------------ End of Software Engineering Digest ******************************