Business Object Notation

Abstract: The emerging Unified Modelling Language has been touted as merging the best features of existing modelling languages, and has been adopted by leading companies and vendors as a universal software modelling language. Some researchers are also looking to UML as a basis for formal methods development. A less known approach is BON (the Business Object Notation), which is based on the principles of seamlessness, reversibility and design by contract, making it an ideal basis for industrial-strength formal methods development of objectoriented software. In this paper, we argue that BON is much more suited for the application of formal methods than UML. We describe the properties that an industrial-strength formal method must have, show how algorithm refinement can be done in BON (as an example of using BON for formal development), and contrast BON with other approaches, including UML, Z, B and VDM.

Abstract: The article shows how to make a transition from the Z formal notation to the Business Object Notation (BON). It is demonstrated that BON has the expressive power of Z, with the additional advantages of object-orientation and a supporting seamless development method. The transition is illustrated for some widely used Z constructs. The translation lays the groundwork for a semi-automated tool for extracting classes from Z specifications.

Abstract: Business Object Notation, commonly known as BON, is a method for analysis and design of object-oriented systems, which emphasizes seamlessness, reversibility and software contracting. Its aim is to narrow the gap between analysis, design, and implementation by using the same semantic and conceptual base for the notation on all three levels. The idea is that if a method is to serve as support for the whole life cycle of a system, it must be possible to use its models and notations to do both forward engineering and reverse engineering. It must be possible not only to transform an initial problem model into an executable system, but also to reflect source code changes back into design and analysis. Therefore, in BON you will not find the usual entity-relationship diagrams and state-charts that form the basis of nearly all analysis and design methods on the market today (whether claiming to be object-oriented or not). The reason is that no matter what you think about the expressiveness of these modeling concepts, they are incompatible with what is available at the implementation level, and so effectively prevent reversibility. Instead, BON relies on the power of the pure object-oriented modeling concepts: a system as a set of classes (abstractions) which are related by inheritance and client dependencies. The O-O concepts are combined with a clustering mechanism to group related abstractions, and with precise component specification based on strong typing and software contracts. The BON method is fully described in the book Seamless Object-Oriented Software Architecture, Prentice Hall 1995 [1]. It includes concepts and notations for static and dynamic modeling of object-oriented software as well as detailed guidelines for the modeling process. The short overview in this chapter will concentrate on the general principles underlying the design of BON and the resulting concepts and notations, while there will only be room to touch upon the modeling process. Readers who want more detail are referred to the book above, in which more than 200 pages are devoted to the software process: describing the method guidelines and applying them in three extensive case studies drawn from practical usage.

Abstract: In this paper we will compare and contrast some of the newer methods with some of theestablished methods in the field of object-oriented software engineering. The methods re-viewed are Solution-Based Modelling, Business Object Notation and Object BehaviourAnalysis. The new methods offer new solutions and ideas to issues such as object identi-fication from scenarios, traceability supporting techniques, criteria for phase completionand method support for reliability. Although all these contributions, we identified someissues, particular design for dynamic binding, that still have to be taken into account in anobject-oriented method. 1. Introduction The past years have seen the emergence of quite a number of different methods for object-oriented development. Although many of them have now been applied and tested on manyreal-world projects from which experience reports have been published, the softwaremanager is still facing a daunting task when he is to select the best method for his organ-isation. Furthermore, the area is still evolving and new methods continue to appear everyyear. A major problem is that terminology and style of presentation make the methodslook more different than they really are, thereby obscuring the truly differentiating issues.In this paper we will evaluate some recently published object-oriented methods and high-light those features which are truly innovative contributions. The methods which havebeen studied are [Gol92], [Ner93],[Rub 92].