{"title":"Patterns: building blocks for object-oriented architectures3","authors":"B. Anderson, P. Coad, Mark Mayfield","doi":"10.1145/260303.260347","DOIUrl":"https://doi.org/10.1145/260303.260347","url":null,"abstract":"Reporter's note: this is my own choice of how best to present our work in the space available. A brief account precedes a list of patterns, and the polished version of one example in full. Work process Call-stress definite outcomes; insist on use of fixed template; give examples Beforehand-circulate all accepted patterns to participants Arrival-music, badges, a vigorous game Divergent phase-a guided fantasy on \" powerful uses of patterns in the workplace, \" leading to impressionistic posters by small groups, on the function of patterns. Working-Relining of patterns, in small groups where the author was interviewed and then members worked on both the pattern and the writeup. Integrating-authors made posters about their patterns, on flipchart sheets, illustrating them graphically and attaching their revised writeups. Then we walked around looking at each others' work, and discussing it. Closure-a circle where we each said something we had learned during the day, and agreed to circulate our revised patterns. This structure is successful because of (a) commonality of interest and commitment, through submitting a pattern in the agreed format, (b) commonality of background through having read the circulated patterns, (c) creation of a safe and motivating atmosphere by the leaders, (d) worthwhile tasks to do, and (e) sharing of results. Note especially that we had no presentations at all during the workshop-1 believe that the passivity Addendum to the Proceedings OOPSLA'93 and inequality they force on an audience is very hard to transform into productive work, and the enjoyment that such work brings. Short description: Whenever the variation between systems or subsystems or versions is in the way of carrying out some operation, make the operation into a strategy object. Contrast this with making it a member function. Short description: For a collection, let each member do as much as it can; limit the behavior of the overall collection to things that its parts cannot do well. Short description: A 'front-end' hierarchy of classes is developed, knowing that in any given application, nearly all objects will actually be instances of subclasses of EACH class in the hierarchy. By using multiple inheritance plus Factories, applications may create a parallel hierarchy of 'back-end' classes that reuse and build off front-end functionality, without otherwise altering the front-end.","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134310807","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Understanding object-model concepts","authors":"D. Embley","doi":"10.1145/260303.260364","DOIUrl":"https://doi.org/10.1145/260303.260364","url":null,"abstract":"ion produces models that hide detail, extract the essence of objects being modeled, and chunk concepts. Multiple levels of abstraction facilitate the presentation and management of varying amounts of T(x) => P(x) holds, where T is a type for an object n, which, if it holds, implies that certain properties P are true for X. The properties P are usually only signatures, not full semantics. Addendum to the Proceedings OOPSLA’93 137 Generalization/Specialization Given the predicates above for class and type, we can define generalization/specialization for classes and types as follows:","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123598289","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Iterate applications not just prototypes","authors":"John A. Cupparo","doi":"10.1145/260303.260312","DOIUrl":"https://doi.org/10.1145/260303.260312","url":null,"abstract":"In 1990, Texaco launched an initiative to re-engineer its exploration and producing business processes and build an integrated information system to support those business processes. The Texaco Revitalization Initiative (TRI) was formed and divided into two major areas, Land and Gas. The Land initiative focused on the administration of properties in which Texaco has an interest. The Gas initiative focused on tracking the gas from production on a property to eventual sale to an end customer. The goal of both systems is to keep accurate volumes and prices for royalty and revenue calculations. The Land and Gas initiatives were further divided into sub-systems which could be implemented by different teams.","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129158061","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Reengineering legacy systems using GUI and client/server technology","authors":"Owen Walcher","doi":"10.1145/260303.260313","DOIUrl":"https://doi.org/10.1145/260303.260313","url":null,"abstract":"","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"109 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117194800","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Re-engineering design trade-offs in a legacy context","authors":"S. Fraser, Terry Cherry, S. MacKay","doi":"10.1145/260303.260353","DOIUrl":"https://doi.org/10.1145/260303.260353","url":null,"abstract":"Large complex real-time legacy systems are frequently re-engineered by design teams using object-oriented analysis and design methodologies. Design trade-offs are often necessitated by performance requirements, limited market windows, deployment costs and longterm maintenance issues. These systems cannot be reengineered overnight, but require transition strategies where old and new components must coexist and interact.","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"47 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123648800","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Applying software testing practices to an object-oriented software development","authors":"B. P. Chao, Donna M. Smith","doi":"10.1145/260303.260317","DOIUrl":"https://doi.org/10.1145/260303.260317","url":null,"abstract":"This paper describes the experiences in testing an object-oriented software system. The testing activities were integrated into a software quality assurance program so that assurance practices such as inspections were equally important as unit level and system level testings. The test approach employed object-based testing with a focus on testing objects and their features. Results indicated areas such as test coverage and stopping criteria require further research in refining object-based testing.","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"36 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129974235","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Specification of behavioral semantics in object-oriented information modeling","authors":"Bill Harvey, H. Kilov, H. Mili","doi":"10.1145/260303.260332","DOIUrl":"https://doi.org/10.1145/260303.260332","url":null,"abstract":"Foreword This workshop report is organized in five sections: 1) purpose of workshop, 2) logistics, 3) technical presentations, 4) recommendations, and 5) list of participants. To understand an enterprise, make its components reusable and semantically interoperable, precise specifications of behavioral semantics are essential. Further, as objects do not exist in isolation, modeling an enterprise involves modeling the collective behavior of objects that make up the enterprise. The purpose of the workshop was to explore behavioral modeling concepts, especially modeling the collective behavior of objects (using declarative constructs), and behavioral abstraction and refinement approaches for aggregation and decomposition. Some topics of particular interest included formal specification of behavioral semantics and (attempts at) the standardization of information modeling concepts and the specifications of reusable components. The call for participation welcomed contributions by both researchers and practitioners, as we hoped to achieve a cross-fertilization of formal and heuristic/informal specification approaches, and an outline of open practical and theoretical questions that would advance the state of the art and the practice. We received a total of thirty submissions varying in length from 2 pages to full length papers. Those submissions were collected-and some manually edited and typeset!-in a 169 page proceedings edited by Haim Kilov and Bill Harvey, produced by Bill Harvey's home institution, proceedings were sent to the participants two weeks prior to the workshop. Fifteen submissions were selected for presentation during the workshop, under two major tracks: 1) Issues, and 2) Solutions. Under solutions, three loosely recurring themes were identified: 1) modeling of collective behavior, 2) the use of formal methods, and 3) types/roles and operations/events. After some last minute changes, we (28 people at the beginning, a bit less 7 hours later) sat through 12 presentations averaging 10 min each, punctuated with two coffee breaks (did anyone find out where coffee was served, if any?), a late-lunch break, and two \" thematic \" open discussions. There then followed a no holds barred, two-hour cross-fire, by the end of which we all learned how to pronounce each other's names correctly. This workshop builds on a workshop titled \" Object-Oriented Reasoning in Information Modeling, \" organized by Haim Kilov and Bill Harvey in OOPSLA'92 [Kilov & Harvey, 19921. Some of the participants had already participated in the '92 workshop. All of the participants this year expressed the desire to \" do this again. \" 3. Technical Discussions This section is divided into three …","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"71 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115956648","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"The society of objects","authors":"M. Tokoro","doi":"10.1145/260303.260305","DOIUrl":"https://doi.org/10.1145/260303.260305","url":null,"abstract":"In this paper, I will first review the notions of objects and concurrent objects and discuss their main roles. Then, I will introduce two observations on our current computer systems and explain why we need an evolved notion of objects, which we call uut0num014~ agents, to describe open and distributed systems. An autonomous agent is a software individual that reacts to inputs according to its situation and its goal of survival. A collection of such autonomous agents shows emergent behaviors which cannot be ascribed to individuals, eventually forming a society. Research into achieving a society of autonomous agents being carried out at Sony Computer Science Laboratory and Keio University will then be presented. In the last section, I will speculate about yet-to-be-realized computational modules called volitional agents, that could be used to create safe, evolutionarily stable, cohabitating society.","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"9 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125318712","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Software architecture (panel): the next step for object technology","authors":"B. Anderson, M. Shaw, L. Best, Kent L. Beck","doi":"10.1145/260304.260321","DOIUrl":"https://doi.org/10.1145/260304.260321","url":null,"abstract":"Moderator's note: this is a lightly-edited set of extracts from the answers given to audience questions during the panel session, together with a brief excerpt from the following BOF discussion. It is not a comprehensive or balanced treatment of either the panel session or of the panelists' views. The position papers printed in the OOPSLA Proceedings contain further powerful statements by the panelists. I have a very broad definition of architecture and I would define it as really understanding software as a product, and the recurring things you see in software as a product. This can go to the very early stages of development where we are talking about recurring requirements. What are the recurring things that people use applications for, and what are the recurring ways that applications support business processes for instance? You can use architecture as a tool for analysis all the way down to actually assembling predefined facilities or software components, both big ones and small ones. So I would certainly not limit the idea of architecture to logical or physical. I think if you look at other uses of the term outside our particular discipline, then they also adopt a very broad definition of what it is. In software, although there is less consensus and we are less explicit about it, you can still recognize distinct levels of design. The differences have to deal with the issues that you are resolving when you are working at that level of design. So we have an executable level of design, we have a programming level, then we have what I think of as the architecture level where we think about the way that components (which more or less correspond to the compilation units but not quite) are put together to realize the gross function of the system. Here is where we worry about how the overall functionality is decomposed, about how the overall performance budget is partitioned out. We worry about bottlenecks and global throughputs and gross aggregate properties of the system here, and I think if we move up from there you may be above to identify a specification or requirement level where the issue is, what is to be computed, in terms recognized by software people or by users. So when I say software architecture I am meaning the design that resolves the issues at the software system level of the design, excluding the algorithm …","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127813046","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Object-oriented reflection and metalevel architectures {fourth annual}","authors":"B. Foote","doi":"10.1145/260303.260359","DOIUrl":"https://doi.org/10.1145/260303.260359","url":null,"abstract":"This year’s workshop on object-oriented reflection and metalevel architectures generated an unprecedented level of interest, with thirty-one submissions, and in excess of fifty people in attendance. This summary presents but a flavor of the issues that were addressed at the workshop. Instructions for obtaining electronic copies of the attendance list, and the position papers themselves, appear at the end of this summary.","PeriodicalId":297156,"journal":{"name":"Addendum to the proceedings on Object-oriented programming systems, languages, and applications","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129423100","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}