Ian Simmonds

Behavioral Specifications of Businesses and Systems

Preface. 1. Object-oriented transformation K. Baclawski, et al. 2. Being served: The purposes, strengths and limitations of formal service modelling B. Cohen. 3. What vs. how of visual modelling: The arrow-diagram logic of visual modelling Z. Diskin, et al. 4. Meta-modelling semantics of UML A. Evans, et al. 5. Combining JSD and Cleanroom for object-oriented scenario specification M. Frappier, R. St-Denis. 6. What is behind UML-RT R. Grosu, et al. 7. Applying ISO RM-ODP in the specification of CORBA(R) interfaces and semantics to general ledger systems J. Hassall, J. Eaton. 8. Component-based algebraic specifications S. Iida, et al. 9. A meta-model semantics for structural constraints in UML S. Kent, et al. 10. On the structure of convincing specifications H. Kilov, A. Ash. 11. Formalising the UML in structured temporal theories K. Lano, J. Bicarregui. 12. JML: A notation for detailed design G. Leavens, et al. 13. Agents: Between order and chaos J. Odell. 14. UML, the future standard software architecture description language? A. Schurr, A. Winter. 15. Using information modelling to define business requirements M. Shafer. 16. A layered context perspective on enterprises and information systems I. Simmonds, D. Ing. 17. 30 Things that go wrong in object-oriented modelling with UML 1.3 A. Simons, I. Graham. 18. Formalizing association semantics in terminologies H.Solbrig.19. On the specification of the business and economic foundations of electronic commerce A. Thalassinidis, I. Sack. 20. Embedding object-oriented design in system engineering R. Wieringa. Index.

Flexible modeling tools for pre-requirements analysis: conceptual architecture and research challenges

A serious tool gap exists at the start of the software lifecy-cle, before requirements formulation. Pre-requirements analysts gather information, organize it to gain insight, en-vision possible futures, and present insights and recom-mendations to stakeholders. They typically use office tools, which give great freedom, but no help with consistency management, change propagation, or information migration to downstream tools. Despite these downsides, office tools are still favored over modeling tools, which are constrain-ing and difficult to use. We introduce the notion of flexible modeling tools, which blend the advantages of office and modeling tools. We propose a conceptual architecture for such tools, and outline research challenges to be met in realizing them. We briefly describe the Business Insight Toolkit, a prototype tool embodying this architecture.

Using tagging to identify and organize concerns during pre-requirements analysis

Before requirements analysis takes place in a business context, business analysis is usually performed. Important concerns emerge during this analysis that need to be captured and communicated to requirements engineers. In this paper, we take the position that tagging is a promising approach for identifying and organizing these concerns. The fact that tags can be attached freely to entities, often with multiple tags attached to the same entity and the same tag attached to multiple entities, leads to multi-dimensional structures that are suitable for representing crosscutting concerns and exploring their relationships. The resulting tag structures can be hardened into classifications that capture and communicate important concerns.

From dynamic super types to subjects: a natural way to specify and develop systems

When we understand, specify, and develop systems, we use certain concepts and constructs to deal with complexity. Object-oriented (OO) approaches provide good ways for doing so. However, many existing OO approaches (perhaps based on object models used in existing OO languages) cannot solve important problems encountered in large and complex systems. For example, we often have to deal with properties of “things” that cannot be represented in a neat hierarchy. Some of these properties may significantly change with time. Moreover, many of these properties refer to collections of objects without identifying a single object as “owner” of each property. The authors of this technical note have separately proposed approaches for solving these problems, but at very different stages of the development life cycle. However, the underlying concepts of these approaches are so close that they can be successfully combined to provide a common solution that encompasses all stages of the life cycle.

Invariants in the Trenches

This paper demonstrates: that business specification (“analysis”) can be successfully separated from solution specification (“design”); that a precise, compact, understandable, yet complete, business specification for a non-trivial business problem is possible; that technical terminology (eg “invariant”, “generic relationship”) essential for writing such a specification can be quickly understood and freely used by all participants; and that a real-life business analyst (“in the trenches”) of a non-consulting (in this case, insurance) company can become self-reliant and comfortable with the approach in a reasonably short period of time. It does so by presenting both general observations on business analysis, and specific experience from producing a real business specification.

Business Objects and Business Rules

Business object facilities should be designed to enable businesses to implement distributed, object-oriented business applications that reflect the natural structure of the business. They should also provide structures that allow different views on the system to be faithfully captured in its design. For example, information technology experts and business experts have different but equally valid ways of looking at a business application system; both must be captured faithfully if the system is to be useful, flexible, and durable.

An algorithm for identifying the abstract syntax of graph-based diagrams

Diagrams play a key role in the information systems domain. However to be meaningful, the diagrams are understood by interpreting visual cues in specific, conventionalized ways, termed conceptual models. One of the major pain points of conceptual models, specified as visual languages, is the inability to capture these visual languages effectively in conventional modeling tools. Instead, conceptual models are drawn using drawing tools and sometimes even by hand. We propose an automatic procedure to derive the syntactic building blocks of graph-based conceptual models. This high-level specification of the visual language can then serve as input for the automatic construction of syntax-aware diagram editors. Our aim is to achieve minimum effort on the part of the users when they eventually work with the graphical editor to produce a new diagram using the proposed syntax.

Business insight toolkit: Flexible pre-requirements modeling

Pre-requirements analysis requires modeling tools with unprecedented flexibility. The Business Insight Toolkit (BITKit) is a prototype of a new kind of modeling tool, aimed at offering the flexibility of office tools along with many of the advantages of modeling tools.

Business Rules: From Business Specification to Design

A “business rule” precisely describes communities of business things: A business rule is a proposition about business things, relationships between them and operations applied to them, from the business enterprise viewpoint. [X3H7-96] A proposition is an observable fact or state of affairs involving one or more entities, of which it is possible to assert or deny that it holds for those entities. [RM-ODP95] The emphasis in the understanding, specifying, and reusing business rules is on their semantics rather than on (many different) ways of expressing their syntax. Similarly, understanding of a program (and reuse of programming constructs) is possible only based on semantics rather than on a syntax used to express this semantics. A business rule is defined in terms of the (mathematical) notion of “proposition” showing that precision is essential when formulating business rules. An imprecise notion of “business rule” is of no use because it can be applied to almost anything (for example, “business rules are those things supported by mechanism ZYX, which is a business rule mechanism”). When used in this way, the term “business rule” is merely a buzzword, whose value is determined by current fashion. The definitions of business rules do not mention computers, software, programming languages, databases, or any other technological notion. A business rule has to be made explicit even if the rule is “get approval for XYZ from a competent, trusted business expert”. Explicitly documented rules were followed by businesses (and, as legislation, by entire societies) many centuries before computers were invented. Kinds of business rules The diagrammatic specification below shows that a (business) rule can be subtyped (exhaustively) into an invariant, a triggering condition, a precondition, a post-

Blending freeform and managed information in tables (NIER track)

Tables are an important tool used by business analysts engaged in early requirements activities (in fact it is safe to say that tables appeal to many other types of user, in a variety of activities and domains). Business analysts typically use the tables provided by office tools. These tables offer great flexibility, but no underlying model, and hence no consistency management, multiple views or other advantages familiar to the users of modeling tools. Modeling tools, however, are usually too rigid for business analysts. In this paper we present a flexible modeling approach to tables, which combines the advantages of both office and modeling tools. Freeform information can co-exist with information managed by an underlying model, and an incremental formalization approach allows each item of information to transition fluidly between freeform and managed. As the model evolves, it is used to guide the user in the process of formalizing any remaining freeform information. The model therefore helps users without restricting them. Early feedback is described, and the approach is analyzed briefly in terms of cognitive dimensions.