| |
|
Proceedings: The workshop papers are available as technical report from the Munich University of Technology. Unfortunaetly we ran out of copies. Contents of the proceedings.
There is a similar workshop at OOPSLA'98.
Business specifications are essential 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 clear, precise, and explicit way, in order to act as a common ground between business domain experts and software developers. They also provide the basis for reuse of concepts and constructs ("patterns") common to all - from finance to telecommunications -, or a large number of, businesses, and in doing so save intellectual effort, time and money. Moreover, these patterns substantially ease the elicitation and validation of business specifications during walkthroughs with business customers, and support separation of concerns using viewpoints.
Precise specifications of business semantics in business terms provide a common ground for subject matter experts, analysts and developers. If business specifications do not exist, or if they are incomplete, vague or inconsistent, then the developers will (have to) invent business rules. This often leads to systems that do something quite different from what they were supposed to do.
Business specifications (the "what"s) are refined into business designs (the "how"s), from where creation of various information system (software) specifications and implementations based on a choice of technological architecture are possible. In this context, precision should be introduced very early in the lifecycle, and not just in coding, as it often happens. In doing so, "mathematics is not only useful for those who understand Latin, but also for many other Citizens, Merchants, Skippers, Chief mates, and all those who are interested" (Nicolaus Mulerius, one of the first three Professors of Groningen University, early 17th century).
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 are essential when large and even moderately sized systems, both business and computer, are considered. Viewpoints 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 different abstraction levels.
Many concepts and constructs used for all kinds of behavioral specifications - from business to systems - have common semantics and thus are good candidates for standardization and industry-wide usage. Various international standardization activities (such as the ISO Reference Model of Open Distributed Processing and OMG activities, specifically the more recent ones around the semantics of UML, business objects, and other OMG submissions, as well as the creation of OMG semantics working group) are at different stages of addressing these issues. OMG is now interested in semantics for communities of business specifications, as well as in semantic requirements for good (business and system) specifications.
It is therefore the aim of the workshop to bring together theoreticians and practitioners to report about their experience with making semantics precise (perhaps even formal) and explicit in OO business specifications, business designs, software and system specifications. This is the 8th workshop on these issues; we already had 7 successful workshops, one at ECOOP and six at OOPSLA conferences. Reuse of excellent traditional "20-year-old" programming and specification ideas (such as in [1,2]) would be warmly welcomed, as would be reuse of approaches which led to clarity, abstraction and precision of such century-old business specifications as [3]. Experience in the usage of various object-oriented modeling approaches for these purposes would be of special interest, as would be experience in explicit preservation of semantics (traceability) during the refinement of a business specification into business design, and then into a system specification.
The scope of the workshop includes, but is not limited to:
Deadline for submission: June 4, 1998
Notification of acceptance: dynamic
Final version: June 10, 1998
Day of workshop: July 24, 1998
Please note that workshop participants must register at least on that day at ECOOP conference. Deadline for early registration at the ECOOP conference is Friday, June 19th.
will be printed as technical report of the Munich University of Technology and will be available at the conference. As in the year before, we will select the best papers to be published in the workshop reader (probably Springer, LNCS). Please note the submission guidelines.
is http://www.se-rwth.de/~rumpe/publications/ecoop98-ws/ and will contain all informations. You may also contact Bernhard Rumpe.
Workshop proposals should be about 5-10 pages and highlight the main contributions of the author(s). Interesting papers will be selected by the organizers and their authors will have the possibility to present them in about 20-30 minutes. Furthermore, each author is encouraged to present open questions and one or two main statements that shall be discussed. Workshop participants are invited to submit their contribution as Postscript (or if necessary Word) email to rumpe@forsoft.de.
If your interest is more focused on the technological or tool aspects of business rules, or on the construction of a particular object-oriented business process model, there are other ECOOP workshops (see below). Our workshop focuses more on the common concepts and constructs used to specify behavioral semantics throughout the lifecycle, on rigourous ways to represent them and to reuse specification writing, reading, refinement, and implementation.
Last modified: April, 8th, 1998.