Jackson, already in  and especially in the work [43—46, 75] leading up to the seminal , has again and again emphasised the domain, or, as he calls it, the environment aspects. We are not claiming that domain analysis as part of our domain engineering approach is new.
Formal Methods: State of the Art and Future Directions (1996)
We claim it is new to put emphasis on describing the domain formally in isolation from any concern for requirements, let alone software. Section 1. A new contribution here, perhaps, is our treatment of the modelling of entities: atomic in terms of their attributes and composite in terms of their attributes, their sub-entities and the composition, which we refer to as the mereology of these sub-entities. We present some high level pragmatic principles for decomposing the task of describing a domain — in terms of what we call domain facets — and we illustrate facet modelling by some, what you might think as low level descriptions.
Sections 1. Basically this chapter assumes a number of other abstraction principles and techniques which we cover elsewhere — notably in [5,6] and [7, Chaps. We refer to [5, 6] for a comprehensive coverage of formal abstractions and models. Two remarks are now in order. Each, including RSL, has its limitations in what it was supposed to express with ease. The present chapter presents an essence of Chaps.
- Cat Traps (Step into Reading).
- The Puppy Place #22: Bella.
- Laws Of Magic 2: Heart Of Gold (The Laws of Magic).
- Every Day : The Journey of Forty-Years!
- Educational Theory (RLE Edu K): An Introduction (Routledge Library Editions: Education).
- SAP Netweaver Master Data Management Frequently Asked Questions: SAP MDM FAQ.
Reference  represents an extensive revision of the following published papers: [15, 19, 25, 37, 54, 55, 62]. There are a number of other aspects of software engineering which underlie professional domain engineering — such as 1 general principles of abstraction and modelling, 2 special principles of modelling languages and systems and 3 other special principles of modelling domains. These are extensively covered in [5, 6] and [7, Chaps. We see the domain engineering process as composed from and iterated over the following stages:3 1. To pursue items 2—3, one must know what goes into a domain description, i.
This chapter focuses on presenting some of these principles and techniques. From repeated observations we form immediate, abstract concepts. We may then lift such immediate abstract concepts to more general abstract concepts. Phenomena are manifest. They can be observed by human senses seen, heard, felt, smelt or tasted or by physical measuring instruments mass, length, time, electric current, thermodynamic temperature, amount of substance, luminous intensity.
Entities are either atomic or composite. The decision as to which entities are considered is a decision solely taken by the describer. Attributes — Types and Values With any entity we can associate one or more attributes. Example 1. That is, of the relations of part to whole and the relations of part to part within a whole. Example 2.
Transport Net, A Formalisation: A transport net consists of one or more segments and two or more junctions. They are names of attribute types and, as such, designate attribute values.
N is composite, S and J are considered atomic. The pragmatics of the notion of state is that states are recurrent arguments to functions and are changed by function invocations. Function Signatures By a function signature we mean the name and type of a function. I agree. Function Descriptions By a function description, we mean a function signature and something which describes the relationship between function arguments and function results.
Example 4. Events may or may not lead to the initiation of explicitly issued operations. Example 5.
Formal Methods: State of the Art and New Directions : Paul P. Boca :
External events: The second example above illustrates an external action. We assume that we have not explicitly modelled bank robberies! Formal modelling of events: With every event we can associate an event label. Two or more event labels may be the same. The structure may typically be a set of sequences of actions and events. Such a statement is required or implied, however, whenever we present a particular model. A behaviour is either a simple behaviour or is a concurrent behaviour, or if the latter, can be either a communicating behaviour or not.
Example 6. Simple Behaviours: The opening of a bank account, the deposit into that bank account, zero, one or more other such deposits, a withdrawal from the bank account in question, etc. Any sequence in which one or more events are interspersed is also a simple behaviour. Example 7. Concurrent Behaviours: A set of simple behaviours may result from two or more distinct bank clients, each operating their own, distinct, that is, nonshared accounts.
Example 8. Communicating Behaviours: To model that two or more clients can share the same bank account, one could model the bank account as one behaviour and each client as a distinct behaviour. Let us assume that only one client can open an account and that only one client can close an account.
Let us further assume that sharing is brought about by one client, say the one who opened the account, identifying the sharing clients. Now the set of behaviours of the bank account and one or more of the client behaviours is an example of a communicating behaviour.
The modelling of facets is the main aim of this chapter. Thus, there is an assumption, a conjecture to be possibly refuted.
Example 9. Railway Net Intrinsics: We narrate and formalise three railway net intrinsics. A line connects exactly two distinct stations. A rail unit is either a simple i. Simple units have two connectors. Switch units have three connectors.
Simple and switchable crossover units have four connectors. A path, p:P, through a unit, is a pair of connectors of that unit. One can observe lines and stations from nets, line and station names from lines and stations, pair sets of station names from lines and lines names of lines into and out from a station from stations. Axioms ensure proper graph properties of these concepts. The reader is invited to compare the three narrative descriptions with the three formal descriptions, line by line.
Download Formal Methods: State of the Art and New Directions e-book
Example Comparable Intrinsics: We refer to Example 9. We claim that the concept of nets, lines and stations in the three models of Example 9 must relate. Nothing is said about how a state is determined: who sets and resets it, whether determined solely by the physical position of the switch gear, or also by visible or virtual i. Actual Intrinsics In order to bring an otherwise seemingly complicated domain across to the reader, one may decide to present it piecemeal. Then, in a step of enrichment, one adds a few more intrinsic entities, functions and behaviours. And so forth. In order to develop what initially may seem to be a complicated domain, one may decide to develop it piecemeal.
We basically follow the presentation steps: Steps of enrichment — from a big lie via increasingly smaller lies, till one reaches a truth! Software support for activities in such domains typically amounts to database systems, computation-bound systems, real-time embedded systems, respectively distributed process monitoring and control systems.
Railway Support Technology: We give a rough sketch description of possible rail unit switch technologies. In a proper narrative description, the software cum domain engineer must describe, in detail, the subsystem of electronics, electromechanics and the human operator interface buttons, lights, sounds, etc. An aspect of supporting technology includes recording the state-behaviour in response to external stimuli. Figure 1. A switch may go to the switched state from the direct state when subjected to a switch setting s with probability psd. Probabilistic state switching The next example shows another aspect of support technology: the technology must guarantee certain of its own behaviours, so that software designed to interface with this technology, together with the technology, meets dependability requirements.
As such, the techniques and languages for modelling support technologies resemble those for modelling event and process intensity, while temporal notions are brought into focus. Certain lowest-level operational and station-located supervisors are responsible for the day-to-day timely progress of trains within a station and along its incoming and outgoing lines, and according to given timetables. By an incoming and an outgoing line, we mean part of a line between two stations, the remaining part being handled by neighbouring station management.
The larger these enterprises — these infrastructure components — the more need there is for management and organisation. The role of management is roughly, for our purposes, twofold. Firstly, to perform strategic, tactical and operational work and to set strategic, tactical and operational policies, and to see to it that they are followed. Secondly, to react to adverse conditions, that is, to unforeseen situations, and to decide how they should be handled, i.
These either parameterise other, the operations functions, that is, determine their behaviour, or yield results that become arguments to these other functions. Organisation is, thus, a set of constraints on communication behaviours. Hierarchical, rather than linear, and matrix structured organisations can also be modelled as sets of recursively invoked sets of equations.
In both cases, the manager resumes work as from the new state.