This tutorial is an example driven introduction to refactoring: a disciplined approach to changing the design of an existing code base.

This tutorial provides an overview of patterns and principles that we've found useful in designing business information systems.

Interest in the use of processes to provide assistance in software development activities remains at a high level. But the focus of attention has shifted in recent years. Early work emphasizing the study of languages for defining processes was rapidly eclipsed by process evaluation and improvement work, most notably the Capability Maturity Model (CMM). As process improvement has matured as a strategy and philosophy it has also given rise to a strong reaction to the perception that it is unduly ponderous and constraining. Movements such as Extreme Programming (XP) have cast themselves as lightweight alternatives, emphasizing the primacy of freedom and flexibility. Both philosophies and communities continue to grow in size, development, and depth of understanding.The goal of this panel will be to explore the differences between these major approaches to the use of process in software development by bringing together leading articulate exponents of the approaches. Each panelist will be charged with presenting a very concise characterization of the approach being represented. But the focus of the panel will be on understanding the nature of the differences in approach, and the reasons for these differences. Similarities will be sought as well.An underlying hypothesis of the panel is that the differences in approach arise in large measure from differences in objective and differences in assumptions about the software development context. Thus, for example, one approach may be intended to support very long range organizational objectives, while the other may be more tactically oriented. One approach may assume that evolvability is an overriding objective, while another may be more focused on speed to market. One may make stronger assumptions about the skills and training of project personnel. The panel will attempt to delve into these issues to see if it may be possible to suggest criteria for suggesting which approach (and possible adaptation) should be selected for a given development situation.In a larger sense, the goal of this panel is to suggest the possibility of a discipline of software process engineering. Insofar as the panel is able to suggest that development situations can be used to guide the selection of process approaches to the provision of assistance, might this then be an indication that process formalisms could play a role in subsequent specification of detailed processes, and evaluation of their effectiveness?The panel will react to this and related questions. While lively interchanges among the panelists will be stimulated and expected, similar interchanges with the audience will also be cultivated.

In Britain there is a very successful form of panel session, on a television program called “Question Time.” In this programme, four panelists, all public figures, are chosen to give a spectrum of viewpoints. There is always a figure from the two main political p<a.rties, usually one from the third largest party, and some complementary figure, perhaps a a business leader, union leader, or media person. This gives a wide spread of views. There are no position statements, the program is filled by discussing questions at about 10 minutes each. Each question is asked by an audience member, all four panelists respond, moderated by the panel moderator (a well known BBC ligure). The questioner then makes a brief reply, and there is a brief period of comments from the floor. The questions are submitted in advance by the audience members and the progr‘am organizers pick six questions that will be interesting. This panel on use cases follows roughly the same format. A well known (English!) 00 figure will question four expert panelists with differing views, to expose their views and their reasons for differing. There are no position statements, the 90-minute pane1 is filled by discussing eight questions. The questions are submitted in advance by the public and audience members. The moderator picks eight questions that will be interesting and help tease ap‘art subtle issues and differences between the panelists. For each question, all four panelists respond, moderated by the pane1 moderator. The questioner makes a brief reply, and there is a brief period of comments from the floor.

No abstract available.

In the realm of OO methodologies there are two major schools of thought. Both schools claim to define mechanisms whereby software applications can be created that are reusable, maintainable, and robust. Moreover, both schools claim to use abstraction as a key mechanism for achieving these benefits. At issue is whether or not these two schools are fundamentally different, or just variations on an object-oriented theme.Shlaer and Mellor have dubbed one of these schools Translational. In the translational approach, two models are created. One is an abstract model of the application domain which is devoid of any design dependencies. The other model is an abstract model of the design which is devoid of any application dependencies. These two models are composed automatically to yield the code for the system.The other school - supported by Booch, Rumbaugh, Jacobson, and Martin - views the architecture of a system from several different perspectives of abstraction, e.g. logical, physical. These abstractions typically form a layer; abstractions in the logical sense manifest themselves as individual classes as well as collaborations of classes. There may be one layered model, at different layers of abstraction, or, especially given the Objectory view point, there may be multiple models, with an analysis model that's nearly independent from the design model.The panel will explore:• Is there a seamless transition between analysis and design?• Should there be a single model or should there be two - one for the analysis and one for the design?• If there are two models, how are they bridged?• What, if any, are the differences in process between the two schools?• How does architecture manifest itself!• Is there, in fact, a real difference between the two schools of thought?As a result of this exploration, we hope to answer the question: Is translation a myth or is it a reality?

The development of good clinical systems has been impeded by the complexities of clinical medicine. The authors have described a strategy of clinical system development which exploits the benefits of the object-orientated paradigm notably the ability to represent a complex domain. Moreover, clinicians can easily assimilate OO analysis and then apply these techniques to their own domain. They have created a generic data model which is designed to allow representation of all areas of clinical practice and using this model as a common basis for system development will facilitate communication between disparate systems.>