Workshop themes: 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. 1. E.W.Dijkstra. On the teaching of programming, i.e. on the teaching of thinking. In: Language hierarchies and interfaces (Lecture Notes in Computer Science, Vol. 46), Springer Verlag, 1976, pp. 1-10. 2. System description methodologies (Ed. by D.Teichroew and G.David). Proceedings of the IFIP TC2 Conference on System Description Methodologies. North-Holland, 1985. 3. Charles F.Dunbar. Chapters on the theory and history of banking. Second edition, enlarged and edited by O.M.W.Sprague. G.P.Putnam's Sons, New York and London, 1901. Topics The scope of the workshop includes, but is not limited to: * Appropriate levels and units of modularity * Which elementary constructs are appropriate for business and system specifications? Simplicity, elegance and expressive power of such constructs and of specifications. * Using patterns in business specifications * Making Use-Cases useful * Discovering concepts out of examples (Generalization techniques) * Providing examples from specifications * What to show to and hide from the users * How to make diagram notations more precise * Equivalence of different graphical notations: "truth is invariant under change of notation" (Joseph Goguen) * Semantics above IDL * Rigorous mappings between frames of reference (e.g. business and system specifications) * Role of ontology and epistemology in explicit articulation of business specifications * Formalization of popular modeling approaches, including UML * On complexity of describing semantics     «

Workshop themes: 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 telecommunicat...     »