OOPSLA '97
October 5-9, 1997 - Atlanta, Georgia

Workshops: Monday

 

(17) Object Technology and Product Lines: What's the Connection?

Many organizations that produce related software products within a specific market have discovered that they can amortize their technology investments across those products by adopting a product-line approach. A product line is a group of products sharing a common, managed set of features that satisfy specific needs of a selected market.

The potential costs and benefits associated with a product line are substantial. For software-intensive systems, a product line approach involves a sizable initial investment plus continuing maintenance costs. However, the potential benefits include reduced time to market, improved schedule and cost predictability, and improved product quality.

Object-oriented technical practices, such as the modeling of the problem domain and incremental development of systems would naturally support a product line approach. Further, the technical issues being addressed by the object-oriented community are also being addressed by the product line community; issues such as: (1) What is the role of the architecture in the successful development of software systems? (2) What is the relationship between the software architecture and reuse? (3) How can an organization successfully achieve systematic reuse? (4) How can anticipated future changes to a system be planned for? (5) How can the changes to reusable software assets be managed?

The theme of this workshop is "How do current object-oriented technical practices support or hinder a product line approach?"

The focus of the workshop is technical. We are primarily interested in the experiences of the participants in the application of object technologies to a software product line. The problems to be addressed include: (1) What object technologies are being used to support a product line approach? - What are the associated costs and benefits? (2) What measures were used? What were the results? Were the results validated? (3) What were the technical risks? How were they mitigated? (4) What technical issues remain open?

Prospective workshop participants are required to submit a position paper (plain text via email) describing their experiences with software product line developments and the impact of object technology on that development. We will select the participants based on the quality and relevance of their position papers. We will limit the number of participants to 15, and the number of presentations to 5. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Gary Chastek
Software Engineering Institute, Room 4422
4500 Fifth Avenue
Pittsburgh, PA 15213-3890 USA
Email: gjc@sei.cmu.edu
Phone: +1-412-268-2826

Felix Bachmann
Carnegie Bosch Institute

 

(18) CORBA and the WWW

The past year has seen a lot of advances in Web based technology and CORBA: with several implementations of a CORBA/Java mapping and vendor adoption of CORBA technology (Netscape, Oracle et al.). Through the WWW we will see thousands, even hundreds of thousands, of potential clients of distributed systems. Java has also been rapidly developing and is becoming widely adopted. There is a definite convergence of these technologies.

There are questions regarding the construction of Web based architectures using CORBA. The objective of this workshop is to bring together people working with these technologies and provide a forum to discuss the technical issues and experiences of CORBA and the WWW. Topics of interest include: (1) What Analysis and Design issues have to be taken into account when building CORBA architectures for the Web? (2) How does CORBA compare to Java RMI for Web based applications? (3) Will CORBA provide the basis of component ware for the Web and how will this work with such component technologies such as Java Beans? (4) If Java is used for the client side of a CORBA based solution then how much infrastructure can be included within a Java applet? (5) Experiences in deploying this technology - examples of actual use of this technology and how it has been applied. (6) The Internet is notorious for security problems, how does this affect the design and deployment of a CORBA based system? (7) Another aspect of Web security is the Firewall. What does it mean to allow IIOP based communications through the Firewall and what are the implications?

Prospective participants are invited to submit a position paper or experience report (no more than 5 pages) preferably in HTML. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Henry Balen
Fusion Systems Group
One Wall Street Court
New York, NY 10005 USA
Email: balen@acm.org
Phone: +1-212-376-6300
Fax: +1-212 376 6320

Annrai O'Toole
Iona Technologies

 

(19) From Objects to Agents

This Workshop addresses a new theme for the OO community: What is the relationship between objects and agents? Objects can certainly be used to implement agents. But more interesting is the question whether agents can replace objects as more powerful "units of thoughts" for Software Development.

While agents have recently become wildly popular there is no consensus on definitions. Agenthood covers systems that act as filters on Internet streams, systems that help in scheduling, systems that are (disembodied) full AI entities, but Minsky used agents also to denote tiny units in his Society of Mind. Hence, delineating an agent concept as an extension of objects is the first order of business. A challenge is to find a balance between "stupid" but tractable objects and "smart" but intractable AI entities.

Problem Areas and Discussion Topics: (1) Agents are said to be autonomous. Does this entail that an agent must always have a private thread of control? (2) If an agent is an extended object, should an agent have access to its defining class? If so, can an agent exploit this "knowledge" to enhance itself? (3) An AI agent is likely equipped with problem solving machinery that can be invoked on the fly for quick problem solving, potentially interleaved with plan execution. Should we endow agenthood with some form of automatic problem solving? (4) A collection of agents that constitute a system can be assembled with different "political" regimes ranging from trusted with full cooperation to untrusted and egotistic components. There can be a rigid command and control hierarchy or a flexible organization with negotiations in a market setting. Which domains require which parameters? (5) Is there a taxonomy for agent architectures? and what about agent systems architectures? (6) What is the development process for agent systems? (7) Do we need mobile agents (in Cyberspace)? If so, how do they differ from "normal" agents.

Potential attendees are required to submit a position paper with a minimum of three double-spaced pages, 12 point, postscript (or ASCII) format, on one or more of the proposed topics (or somehow explicitly related to them). Experience reports and research papers are equally welcome. Short tool demos are also be acceptable. A selected number of these papers will be presented during the workshop. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers

Peter van Emde Boas
ILLC; Depts of Mathematics, Computer Science, Physics & Astronomy (FWINS)
University of Amsterdam
Plantage Muidergracht 24
NL-1018 TV Amsterdam
The Netherlands
Email: peter@wins.uva.nl
Phone: +31 20 525 6065
Fax: +31 20 525 5101

Dennis de Champeaux
OntoOO

Joachim Laubsch
Hewlett-Packard

 

(20) Collaboration in the object development lifecycle

Collaboration - one of the latest buzzwords in the software industry, but what does it really mean? Too often used as a synonym for coordination (assigning meeting times, collecting and distributing notes, engaging in on-line discussions, etc.), real collaboration should be a much richer activity. Objects are touted as the common language that will bring together all the stakeholders in software development: business users, analysts, developers and managers. This may be true, but what is needed to bring the technology and its multiple participants together successfully is a closer look at collaboration techniques and technologies to complement the objects.

Today's software development is a team effort that requires experts in domain, user interface, programming, management, testing, communication, reuse, training, and deployment. With projects and systems so large that individual team members have a difficult time comprehending their entirety, what chance do these individuals have of successfully working together? A new batch of tools emerging to exploit the technology of the Inter/Intra net claim to take computer-aided collaboration to its next logical step. But do they really? Do we really understand the human barriers to collaboration to such an extent that tools and processes can be developed to directly overcome these barriers? This workshop will examine the factors that empower and inhibit the development team through the different stages of the software development lifecycle, and will propose techniques and tools to facilitate successful collaboration.

This workshop will aid the participant in (1) identifying collaboration requirements in the software development lifecycle; (2) identifying people-oriented barriers to collaboration; and (3) designing processes, roles, and tools which defuse these barriers and facilitate a collaborative approach to software development.

Potential participants are invited to submit a 1 - 3 page position paper that falls into one or more of the following categories: (1) Experience reports describing successful or unsuccessful collaborations in software development (2) An analysis of the collaboration requirements in the object development lifecycle (3) Descriptions of people-oriented barriers to collaboration (e.g., location, culture, process maturity, time zone ...) and their effects (4) Proposals for tools and/or processes to support collaboration in object development.

Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Laura Hill
Robertson, Stephens & Co.
601 California Street, 9th floor
San Francisco, CA 94104 USA
Email: l_hill@mindspring.com
Phone: +1-415-248-4205
Fax: +1-415-248-4088

Adrian Kunzle
JP Morgan & Co.

Bernard Horan
Sun Microsystems Labs, Inc

John Nolan
Interworld Technology Ventures

 

(21) Experiences Using Object Data Management in the Real-World

This workshop aims to bring together users and practitioners who have experiences applying various alternatives to Object Data Management in their organizations. The goal is to discuss some of the issues and problems that they have experienced, what solutions they have developed and what lessons they have learned.

Participants can choose to give a short presentation (10 minutes with 5 minutes for questions) or a long presentation (20 minutes with 10 minutes for questions).

Papers will be grouped according to a general category, which will be decided by the organizers, based upon the submissions received. Some of the topic areas may include (but are not limited to): (1) Experiences "rolling-your-own" to Object Data Management; (2) Experiences with Object to Relational mapping; (3) Experiences using particular products; (4) Comparisons of products for particular applications; (5) Use of Object Databases and Object Request Brokers; (6) Use of Object Databases with legacy or heritage systems; (7) Tradeoffs between alternative system designs; (8) Tradeoffs between alternative languages bindings for application development (e.g. Smalltalk vs. C++ vs. Java); (9) The impact of standards; (10) Management issues in adopting Object Databases; (11) Cultural changes required in an organization for the adoption of Object Data Management; (12) Experiences in training staff to new working methods; (13) Case studies; (14) War stories; etc.

Participants will be required to submit two copies of a position paper of approximately 2-4 sheets of paper (1000-2000 words). Electronic submissions (i.e. postscript, plain text, Word for Windows) are greatly preferred. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Participants will need to have at least 6-12 months experience with a particular project to ensure that they can contribute their experiences and lessons learned to date based on actual systems.

Organizers:

Akmal B. Chaudhri
Interoperable Systems Research Centre (I-Op)
Computer Science Department
The City University
Northampton Square
London EC1V 0HB UK
Email: akmal@soi.city.ac.uk
Phone: +44-171-477-8551
Fax: +44-171-477-8587
WWW: http://www.soi.city.ac.uk/~akmal/oopsla97.dir/workshop.html

Douglas K. Barry
Barry & Associates, Inc.

 

(22) Patterns Mining - Domain Analysis (Where Art and Science Meet?)

The purpose of this workshop is to achieve greater understanding of: (1) the contribution of domain analysis and patterns mining in the development of systems (successes in application) (2) the commonality and variability between patterns mining and domain analysis (synergy between approaches).

Participants in the workshop will be people who have sufficient experience with pattern mining/domain analysis to do the following: (1) Describe an approach for domain analysis/pattern mining: that they have used; that they have taught to software developers who have used the approach; or that they have observed software developers use. The description should include the goals of the approach, the activities used in enacting the approach, and the products produced and used during enactment. (2) Describe the results of using a systematic approach for pattern mining/domain analysis, both qualitatively and quantitatively. (3) Describe the challenges in convincing an organization to use domain analysis/pattern mining and the ways that such challenges can be overcome.

Potential participants are invited to submit position papers that discuss their approach, results, organizational investment, and how the success of their approach has been evaluated.

The result of the workshop will be greater understanding on the part of active workers in the field of domain analysis/pattern mining of the effectiveness of different techniques. Participants should take away with them ideas for improving the processes that they are using and developing, and ideas for transitioning those processes into use.

The output of the workshop will be partly determined by the participants during the workshop, but will at least include a collection of position papers by the participants. The participants may also decide to publish such items as a summary of the discussions held during the workshop, a list of questions whose answers would lead to progress in developing and applying domain analysis/pattern approaches, and a set of recommendations based on collective experience.

Position papers not exceeding 2,500 words should be submitted by a URL (preferred), HTML text, or a "plain-text". Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Steven Fraser, Ph.D.
Nortel Enterprise Networks
2305 Mission College Blvd.
Santa Clara, CA 95052 USA
Email: sdfraser@nortel.ca
Phone: +1-408-565-7084
Fax: +1-408-565-5356

Lizette Velazquez
David Laurance
Lucent

Brian Berenbach
Consultant

 

(23) OO Product Metrics

Quantitative Methods in the OO field is an active research area in which we have seen an explosion of interest over the last years from both academe and industry. However, it is generally felt that the field is still very immature, mainly due to the paucity of published validation studies. Meanwhile, new directions for research, such as the complexity of OO design patterns, are expected to further increase the scope of application of quantitative methods within the object-oriented community.

Automated metrics collection will also be a concern in this workshop. OO CASE tool producers are progressively embedding metrics in their tools, sometimes in an ad hoc fashion. On the other hand, traditional metric tools producers are expanding the range of supported languages to include OO ones as well, often with some fuzzy metric selection strategies. This workshop aims to shed some light on recent research results and future directions that might interest not only the academic community but also industry keen to apply quantitative methods to an increasing share of new systems being built using OO technology.

This workshop will provide a forum to discuss the current state of the art and to get an insight into the use of quantitative methods in OO artifacts from analysis to coding. A blend of researchers and practitioners from industry and academia will share recent advances in the field, success or failure stories, lessons learned, and will seek out as yet unidentified fundamental problems arising in this field.

The emphasis of this workshop is expected to build on the successful outcomes and directions established by the OOPSLA '96 Product Metrics Workshop particularly inviting papers on the following topic areas: (1) Relationships between OO product and process metrics (such as defects and effort); (2) Standards for the collection, comparison and validation of metrics; (3) Empirical validation of OO metrics; (4) Reliability and rework effort estimates based on design metrics; (5) OO metrics versus quality attributes (reliability, portability, maintainability etc.); (6) Measuring size and complexity at the analysis phase; (7) Measuring size and complexity of design patterns; (8) Metric based design heuristics; (9) Embedding metrics in OO CASE tools; (10) Tools for OO metrics collection; (11) Formal validation of OO metrics; (12) Metrics for OO formal languages (Object Z, Z++, VDM++, TRIO+, OSDL,...); (13) The workshop format will include the presentation of selected submitted papers, group discussions and potentially some tool demonstrations.

Potential attendees are required to submit a position paper with a minimum of three double-spaced pages, 12 point, postscript (or ASCII) format, on one or more of the proposed topics (or somehow explicitly related to them). Experience reports and research papers are equally welcome. Short tool demos will also be accepted. A selected number of these papers will be presented during the workshop. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Philip Haynes
Object-Oriented Pty Ltd
Level 11
75 Miller Street
North Sydney 2060
NSW
Australia
Email: p.haynes@oopl.com.au
Phone: +61 2 9957 1092
Fax: +61 2 9956 5089

Brian Henderson-Sellers
Swinburne University of Technology, Australia

Fernando Brito e Abreu
INESC

Simon Horner
IBM Corporation

Dennis de Champeaux
OntoOO

Granville (Randy) Miller
Make Systems

 

(24) Requirements Engineering: Use Cases and More

"How do we know that we are developing the right software?"

"How do we know that we are developing the software right?"

These are the two fundamental questions that all software developers must ask themselves. Most developers seem to agree that use cases are a useful tool for requirement analysis. Unfortunately, there is little agreement on the form and purpose of use cases. There is little published material to guide projects. As a result many projects suffer when starting out with use cases for the first time.

The objective of this workshop is to provide guidelines and rules-of thumb to help projects using use case based requirements analysis.

Interested participants in this workshop are requested to submit a (text only) paper containing: (1) Name and affiliations. (2) What you want to get out of the workshop and why you wish to participate. (3) The roles you have played in the requirements process - customer, software developer, project manager.

Include a short (one/two paragraph) statement on one or more of the following discussion points: (1) What is requirements analysis? Is it a distinct phase? What is the difference between Requirements Analysis and Object-Oriented Analysis? (2) What is the proper form for a Use Case, based on Cockburn's classification (http://members.aol.com/acockburn/papers/usecases.htm) (3) Are Use Cases sufficient for Requirements Analysis? What other models are necessary? (4) What should a use case contain? What should a use case not contain? (5) What are the main problems encountered during requirements analysis? What are the most important criteria for successful Requirements Analysis? (6) How should an analyst specify quality constraints? (7) When is Requirements Analysis finished? What is a sufficient model?

The submission statements will be published on the web at http://www.pols.co.uk/workshop97.htm. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Andy Pols
Pols Consulting Limited
11 Queensway Close
Penwortham
Preston
Lancashire PR1 OEH
UK
Email: andy@pols.co.uk

Dan Rawsthorne
BDM Air Safety Management Company

 

(25) Object-Oriented Technology for Service, System and Network Management

As networks are becoming as commonplace as PCs and the demand is increasing toward seamless integration of computing and communications resources into ever-more user-friendly enterprise management, the challenges faced seem endless. One of the technologies that needs to be applied to master this complexity is object orientation. Authors are invited to submit either original research contributions, or experience reports that provide new insight into the use of object-oriented technology for integrated resource management in telecommunications. The term "resource" includes network, system, service and application resources. Areas of interest include, but are not limited to: (1) Object-oriented technology for the Management of Computer/Telecommunications/Wireless Networks, Distributed Systems, Multi-Media Systems, and Telecommunications Services; (2) Object-oriented concepts for network management standards; (3) Object-oriented methods for the design of management applications; (4) Object-oriented databases for the storage of managed objects; (5) Managed objects behavior; (6) Managed objects relationships; (7) Object-oriented model for management policies; (8) Multiagent systems for distributed network management; (9) Agent technology applied to management by delegation; and (10) Test, verification and validation of object-oriented management systems.

Submissions should be written in English and no longer than 2,000 words. A separate cover sheet must be included which provides the following information: title, authors' names, postal and electronic mail addresses, telephone and fax numbers, a ten-line abstract and a list of keywords. Electronic submission is highly recommended. If you send a printed submission, please send 4 copies.

Deadline for submission of papers is July 15, 1997. Notification of acceptance will be mailed by August 15, 1997.

Organizers

Simon Znaty
ENST-Bretagne, Dept RSM
Rue de la Chataigneraie, BP 78
35512 Cesson-Sevigne
France
Email: znaty@rennes.enst-bretagne.fr
Phone: +33 2 99 12 70 38
Fax: +33 2 99 12 70 31

Olivier Festor
INRIA, France

 

(26) Object Technology, Architectures, and Domain Analysis - What's the Connection? - Is there a Connection?

OOPSLA has held previous sessions on the roles of domain analysis and architectures in domain / product line engineering. These have tended to focus on analysis methods or on object technology for domain analysis. This workshop wants to look the other way: what can domain analysis bring to object technology and how does architecture connect? It hopes to build on previous work at the recent Workshop on Software Reuse. (See: http://www.sei.cmu.edu/technology/mbse/wisr_report.html).

Anecdotal evidence of the application of object technology is that over time, an organization produces more subclasses with each new application rather than reusing existing classes. These subclasses become the "property" of each project and are not shared. What causes this proliferation and prevents systematic reuse? How can we address this problem?

Domain analysis and architecture make a necessary contribution to object technology: a focus on understanding the common capabilities of software applications within a product line and on ways to structure and evaluate solutions. At one time, these technologies seemed to be headed in different directions. New approaches in scenarios, use cases, concerns/aspects, frameworks and design patterns have blurred many of the distinctions. This workshop will explore issues involved in moving towards a more unified (to reuse a term) view. We will try to understand the differences between the various technologies and how to make best use of these new approaches.

The workshop will be limited to no more than twelve participants, chosen on the quality and diversity of positions they offer. We are looking for position papers limited to 2500 words in length. The position papers should discuss possible links between domain analysis, architecture and object technology, or, alternatively, why these links cannot be made. Issues may include: (1) how do object-oriented methods address reuse (strengths and weaknesses)? (2) what do the various "new" concepts (e.g., use cases, hot spots, frameworks, concerns/aspects) add? (3) what can domain analysis / models contribute? (4) what can software architecture contribute? (5) are the tools and representations compatible? (6) should these techniques be unified? (7) how can these techniques be unified?

We want to avoid presentations of methods and, instead, concentrate on interactions and results. We also want to know what has and has not worked, and why. In addition to the position paper, each participant should be prepared to give a short (10 minute, 5 slide maximum) overview of a potential connection between the workshop themes. Talks should provide a starting point for discussion related to the workshop topic.

The workshop activities will include pre-distribution of the position papers, group discussions, and round table summary to be captured as a workshop report. The workshop report and all position papers accepted will be posted on a web-site, and participants should agree to have their materials published that way.

Please submit position papers to the organizers in text or html formats via e-mail, submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Sholom Cohen
Software Engineering Institute
Room 5414
4500 Fifth Avenue
Pittsburgh, PA 15213-3890 USA
Email: sgc@sei.cmu.edu
Phone: +1-412-268-5872
Fax: +1-412-268-5758

Fred Maymir-Ducharme
Lockheed Martin Corporation

 

(27) OO Behavioral Semantics (with an Emphasis on Semantics of Large OO Business Specifications)

Business specifications are used to describe and understand businesses (and, in particular, business rules) independently of any computing systems used for their possible automation. They have to express this understanding in a simple, clear, precise, and explicit way, in order to provide the essential common ground between business domain experts and software developers.

For example, they do not have to provide an owner for system state or behavior (as in message passing): such owners are required by legacy OO approaches which have nothing to do with business specifications.

Concepts and constructs ("patterns") common to all, or a large number of, businesses have been specified for reuse, leading to savings in intellectual effort, time and money. Moreover, these precise business patterns substantially ease the elicitation of business requirements during walkthroughs with business customers, and support separation of concerns using viewpoints.

Business specifications (the "what"s) are refined into business designs (the "how"s), from where refinements into various information system (software) specifications and implementations are possible.

Precise specification of semantics - as opposed to just signatures - is essential not only for business specifications, but also for business designs and system specifications. In particular, it is needed for appropriate handling of viewpoints which exist both horizontally - within the same frame of reference, such as within a business specification -and vertically - within different frames of reference. In order to handle the complexity of a (new or existing) large system, it must be considered, on the one hand, as a composition of separate viewpoints, and on the other hand, as an integrated whole, probably at a different abstraction level.

The aim of the workshop is to bring together theoreticians and practitioners to report on their experience with making semantics precise (perhaps even formal) and explicit in OO business specifications, business designs, and system specifications.

The scope of the workshop includes, but is not limited to: business specifications, precise specification of semantics, semantics of OO modeling approaches, semantics-preserving refinement strategies, viewpoint modeling, standards, business patterns (reusable fragments of specification), and related tool support.

Proceedings will be printed as a technical report of the Munich University of Technology and will be available at the workshop.

Submissions are due August 4th, notification of acceptance will be made by August 18th.

Workshop proposals should be about 5-7 pages and submitted as standard postscript or MS Word files, and must be sent electronically. Authors are encouraged to present open questions, together with one or two main statements suitable for discussion.

Organizers:

Bernhard Rumpe
Institut fur Informatik,
Technische Universitaet Muenchen
80333 Munich, Germany
Email: rumpe@informatik.tu-muenchen.de
WWW: http://www.forsoft.de/~rumpe/oopsla-ws/

Haim Kilov
Merrill Lynch

Ian Simmonds
IBM T . J. Watson Research Center

 

(28) Business Modeling for OT systems

Is OT modeling the best approach to modeling a Business? Can OT modeling best encapsulate Business Processes and Rules? What are the tangible benefits of using Objects for Business modeling? How useful is the distinction between Business Use Cases and System Uses Cases? What is the relationship and traceability from Business Models to IT Models? How can Business Language Analysis help? What patterns emerge from applying IT constraints to Business Models?

Building software systems requires excellent understanding of the domain one is working in. Building software systems for a business therefore, requires understanding the business organization, processes and rules.

Even if business reengineering is not the goal of a project and business processes are left unchanged, the current situation has to be documented to get a profound understanding in which business environment the system is going to be placed.

The desire of building reusable software makes it even more important to know what is stable in a domain and where flexibility is needed. What patterns are involved in modeling these aspects?

How appropriate/adequate are the principles of O-O for BM? Some claim that objects are intuitive also for domain experts and therefore are a good means to describe a business. Approaches have been suggested, see Jacobson and Taylor.

Others might contend that it is not so easy to describe business processes through objects and responsibilities, because the most important concepts you are looking at are events and activities. This is not really a contradiction; a combination of both approaches may be feasible.

What are the real benefits of using objects for describing or even re-engineering a business? Of course, it helps bridging the gap between business models and IT systems. Some people claim to get more highly optimized processes through using objects. Can we also hope for other often named benefits of OO, like reusability or easier maintenance?

When judging how adequate O-O is for BM, we have to talk about the kind of models (in terms of diagram types) and concepts we are using. There is probably a high agreement that Class Diagrams are a good means to express a static view of the business with the relevant object types, relationships or rules. However, ideas differ in a minor way like i.e., which stereotypes are being used, what kinds of relationships are reasonable or if dynamic classification should be allowed.

When it comes to dynamic models which describe business processes, one should look at concepts like events and activities, organization roles etc. Object Interaction Diagrams may be inappropriate to document this, and they are not always helpful for the communication with end-users. If this is the case which diagram types and concepts are efficient for modeling business processes then?

Patterns have proved useful for software development. How can Pattern languages be used to describe business problems and possible solutions in a business domain? Fowler has begun to describe common Business Object Model patterns, can these be extended?

Participants of the workshop will be expected to: (1) have experience in business modeling (not necessarily with an OO approach); or (2) write a position paper (of 1 typed page) outlining (or detailing) their views on this topic. Experience reports where O-O modeling was successful or failed in some aspect and research papers are equally welcome. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Steffen Schaefer
IBM EMEA Object Technology Practice
Email: steffen_schaefer@vnet.ibm.com
phone: +49 172 7325807
fax: +49 89 201 1224796

Simon Horner
IBM Object Technology Practice

 

(29) Patterns in Software Architecture

Software architects are faced with a diverse set of problems when they begin to design a system. Many development projects address intrinsically complex problems with limited resources. The evolution of requirements is expected, particularly as developers and users come to better understand the problem through the delivery of early system releases. The software architect must articulate a "vision" for the system which encompasses the different dimensions of the solution to all of the stakeholders. This vision must be both abstract and detailed, providing the development team with a general understanding of how the system is structured and how it operates, while simultaneously providing each specialist with a set of constraints on the design and implementation of their components.

This full-day workshop seeks to continue the work started during previous Patterns in Software architecture workshops (and the Architecture Handbook workshops that preceded it). The workshop will focus on the discovery and linking of patterns for generating software architectures, as well as the identification of patterns to guide organizations on how to successfully implement these architectures.

Our goal is to begin to link these patterns together into a pattern language to be used by software architects in the transformation of system requirements into an architectural design. The workshop session will provide a forum for the discussion of common architectural design problems by software system architects with diverse backgrounds and experiences.

Prospective attendees are requested to submit a position paper (2-4 pages) describing their experiences generating and implementing software systems architectures. Submissions should consider topics such as: How do you identify the areas of your design which require the greatest amount of change resiliency? Where in the design cycle do you distinguish between the components which you are going to acquire, and the components you are going to build? What techniques do you use to present the architecture to the rest of the development team? To project management? To the user or client? How do the available skills of the development team affect your architectural design? Position papers may present new patterns identified from design or implementation experiences; refactor existing patterns; or weave together new and existing patterns to form a pattern language for software architecture. The ideal submission will include both descriptions of concrete experiences developing software architectures (a.k.a. stories) and generalizations drawn from these experiences. Researchers interested in participating should contact the organizers with proposals describing how they can contribute to advancing the state of the art, possibly through education.

Submissions must be made by electronic mail in plain text or Hyper Text Markup Language (HTML) by August 5th. Applicants will be notified by August 18th and submissions will be made available from a WWW site by September 15th.

Organizers:

Tom O'Rourke
PaineWebber Inc.
Email: tom_orourke@acm.org

Gerard Meszaros
Object Systems Group

Bruce Anderson
IBM EMEA Object Technology Practice

 

(30) Business Object Design and Implementation III

The NCITS X3H7 Object Information Management Committee and the Object Management Group Business Object Domain Task Force (BODTF) will jointly sponsor the Third Annual Workshop on Business Object Design and Implementation. This year's workshop will focus on patterns and workflow, areas of high interest in 1996, as well as component design for Web-based applications, an increasingly important focus in 1997.

The Workshop provides a forum for pattern literature on the specification, design, and implementation of interoperable, plug and play, distributed Business Object components. It will continue to help clarify the design and implementation of object-oriented workflow systems, particularly systems in which workflow is an inherent part of a larger architecture, rather than an add-on. An ongoing task is to assess the emerging standards for component design, particularly responses to the OMG Business Object Domain Task Force RFP on a Business Object Facility and Common Business Objects. This year we are also seeking papers that contribute to emerging architectures for business object component design for Intranet/Internet applications, particularly those applications that integrate business objects, web servers, object and relational databases, and new approaches to client delivery of content.

What design patterns are particularly relevant to Business Objects? What are components? How should they be specified? Visualized? What common components should be implemented to support multiple application domains? Are there common design patterns that cross domains? How can these components be assembled into domain specific frameworks? What are appropriate architectures/mechanisms for implementing these frameworks as Internet/Intranet/Extranet distributed object systems? Where are these systems being implemented today? Where are they in production?

All submissions will be posted on the WWW. Those papers generating high interest on the Web will be presented at the Workshop. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Jeff Sutherland
IDX Systems Corporation
269 Highland Avenue
Winchester, MA 01890-3105 USA
Email: jeff.sutherland@idx.com
Phone: +1-508-366-3888 x3728
Fax: +1-617-721-1226
WWW: http://www.tiac.net/users/jsuth/oopsla97/

Cory Casanave
OMG Business Object Task Force

Haim Kilov
Merrill Lynch

Joaquin Miller
MCI Systemhouse

Dilip Patel
South Bank University

 

(31) Evolving Software in Large Scale Persistent Systems

The dominant activity of the large-scale software industry is the modification of existing application systems. Lifetime maintenance costs for large software systems account for between 50% and 90% of the total project expenditure. As application systems live longer and increase in size and complexity, this figure continues to grow. The maintenance of such systems is made more complex by the need to access persistent data (both semi-structured and in databases) with software that is continually evolving.

This workshop will address the very real problems faced by implementors of large, evolving systems, looking both at current technology and open problems. The meeting will focus in particular on two major problems: evolution of software in large scale systems, and access to persistent data by continually evolving software.

This workshop will bring together both practitioners who are building large scale software systems that are capable of being evolved, and researchers who are investigating the architecture and implementation of such systems, at all levels of a computer system's architecture: from the operating system, up through the application programming language to run-time support systems and software development environments.

Other issues that could be addressed include, but are not limited to: (1) Modification of legacy systems to increase their adaptivity. (2) Language support for evolution in large scale systems and its impact on the system architecture and runtime. (3) The approach taken to evolution in systems such as CORBA and OLE-DB. (4) The applicability of semi-automated tools for object transformation.

Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Huw Evans
Department of Computing Science
University of Glasgow
Glasgow G12 8QQ
UK
Email: huw@dcs.gla.ac.uk
Phone: +44 (141) 330 6044
Fax: +44 (141) 330 4913
Answerphone: +44 (141) 330 4946
WWW: http://www.dcs.gla.ac.uk/~huw/oopsla97/workshop.html
WWW: http://www.cs.washington.edu/homes/tiwary/oopsla97workshop.html

Peter Dickman
University of Glasgow

Douglas S. Lea
SUNY

Rajendra K. Raj
Morgan Stanley

Ashutosh Tiwary
Boeing

 

(32) Use Cases and Business Rules: Styles of Documenting Business Rules in Use Cases

Use cases are a preferred medium to document business requirements. Business rules are guidelines or policies that govern how businesses operate. Incorporating the policies into use cases highlights the rules, impacts on the requirements. Many styles exist in the industry for incorporating business rules into use cases. Some examples are: creating a few large use cases, creating many smaller focused use cases, or creating a business rules repository cross referenced to use cases. Although all styles can accurately document the same business rules, practitioners struggle over which style to choose and the impact of the choice on development activities. The purpose of this workshop is to discuss styles submitted by each workshop participant and to develop a style glossary.

Participants must submit a position paper (3-8 pages) describing the style they use to incorporate business rules into use cases and submit a complete example that demonstrates the style. The complete example should include all use cases, alternate courses, abstract use cases, other use case variations and any other documents that are required to support the style described in the position paper. (If the participants' work is proprietary, the organizers will provide a case study for the participant to use to formulate their example.) The example must be included with the paper submission.

If selected, each workshop participant will receive a packet of all participants, submissions and the definitions of common terms for use cases and business rules. Each participant should review the materials prior to the start of the workshop. During the workshop each participant will give a brief presentation that includes a description of the style, the criteria and rationale supporting this style, and the impact of the style on subsequent development activities. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

Rosemary Brinko
American Management Systems
14033 Denver West Parkway
Golden, Colorado 80401 USA
Phone: +1-303-215-3559
Fax: +1-303-215-7566
Email: rosemary_brinko@mail.amsinc.com (Preference is email, ASCII format)

Ed D. Anderson
Mike Bradley
BellSouth Telecommunications

 

(33) OO Project Management

Projects succeed or fail for many reasons. The technology employed on a project is rarely the predominate factor determining success or failure. Effective, or faulty, project management can often be attributed as the predominate factor. Effective project management techniques differ based upon the technology being used, and these techniques have a tremendous effect on the outcome of a project.

We will: (1) Explore some of the different ways to structure project teams and development processes in object technology; (2) Examine the strengths and weaknesses of the different models that are developed; and (3) Discern which issues that arise are general to all software development and which are unique to Object technology.

In teams the workshop participants will be asked to design the team structure and process model for a development project. These designs will then be presented to the remainder of the group and examined from the point of view of managers, developers, customers, and other interested parties.

Potential participants should submit a paper of no more than 2-3 pages in length. The submission should include brief biographical information about the applicant describing any relevant experience in OO project management as well as a discussion of one or more of the following topics: (1) The best development project that you have ever worked on. Why was it the best? How was it structured? What about the structure/management of the project did you like? Dislike? Describe the development process. Did the process work? Why? (2) The most colossal failure of a project that you ever worked on? Why did it fail? How was it structured? What about the structure/management of the project did you like? Dislike? Describe the development process. Did the process work? Why? (3) How do you structure OO development projects? What process do you use? What do you like about it? What don't you like about it?

The position papers will be reviewed by the workshop committee and acceptance will be based on the relevance of the technical material and on the insight the papers provide on the workshop objectives. Submissions are due August 4th, notification of acceptance will be made by August 18th.

Organizers:

John Heidelberger
American Management Systems
1 Chase Manhattan Plaza
36th Floor
New York, NY 10005 USA
Email: john_heidelberger@mail.amsinc.com
Phone: +1-212-612-3665
Fax: +1-212-612-6012
WWW: http://www.amsinc.com

 

 

 

[ OOPSLA '97 Home Page | SIGPLAN | ACM ]