Manifest domains: analysis and description

Abstract

Abstract.We show that manifest domains, an understanding of which are a prerequisite for software requirements prescriptions, can be precisely described: narrated and formalised. We show that such manifest domains can be understood as a collection of endurant, that is, basically spatial entities: parts, components and materials, and perdurant, that is, basically temporal entities: actions, events and behaviours. We show that parts can be modeled in terms of external qualities whether: atomic or composite parts, having internal qualities: unique identifications, mereologies, which model relations between parts, and attributes. We show that the manifest domain analysis endeavour can be supported by a calculus of manifest domain analysis prompts: is entity, is endurant, is perdurant, is part, is component, is material, is atomic, is composite, has components, has materials, has concrete type, attributenames, is stationary, etcetera; and show how the manifest domain description endeavour can be supported by a calculus of manifest domain description prompts: observe part sorts, observe part type, observe components, observe materials, observe unique identifier, observe mereology, observe attributes. We show how to model attributes, essentially following Michael Jackson, [Jac95], but with a twist: The attribute model introduces the attribute analysis prompts is static attribute, is dynamic attribute, is inert attribute, is reactive attribute, is active attribute, is autonomous attribute, is biddable attribute and is programmable attribute. The twist suggests ways of modeling "access" to the values of these kinds of attributes: the static attributes by simply "copying" them, once, the reactive and programmable attributes by "carrying" them as function parameters whose values are kept always updated, and the remaining, the external attributes, by inquiring, when needed, as to their value, as if they were always offered on CSP-like channels [Hoa85]. We show how to model essential aspects of perdurants in terms of their signatures based on the concepts of endurants. And we show how one can "compile" descriptions of endurant parts into descriptions of perdurant behaviours. We do not show prompt calculi for perdurants. The above contributions express a method with principles, techniques and tools for constructing domain descriptions. It is important to realise that we do not wish to nor claim that the method can describe all that it is interesting to know about domains.

Proceedings Joint Workshop on Handling IMPlicit and EXplicit knowledge in formal system development (IMPEX) and Formal and Model-Driven Techniques for Developing Trustworthy Systems (FM&MDD)

“…• I claim that [1] provides an answer to the claim in both [2,3] that ⋄ ⋄ "The contexts of the systems in these cases are treated as second-class citizens . .…”

“…• The domain analysis & description calculi introduced in [1] ⋄ ⋄ is shown to alleviate the issue of implicit semantics [2]. ⋄ ⋄ The claim is made that domain descriptions,…”

“…• Whether such operator-checks be researched and documented ⋄ ⋄ "once-and-for-all" for given "standard" domains, by domain scientists, or • We have suggested that the issue of implicit semantics [2] be resolved ⋄ ⋄ by providing a carefully analysed and described domain model [1] prior to requirements capture and software design, ⋄ ⋄ a both informally annotated and formally specified model that goes beyond [1] in its treatment of attributes ⋄ ⋄ in that these are now endowed with types [and possibly scales (or fractions)] and that each specific domain model analyses and formalises the constraints that operations upon attribute values are carefully analysed, statically.…”

“…• Our approach, [1], summarised in Sect. 2. of this paper, thus represents a formal approach to the description of contexts (i.e., domains) [2, Abstract, Page 1, line 12].…”

Domain Analysis & Description - The Implicit and Explicit Semantics Problem

“…The claim is made that domain descriptions, whether informal, or as also here, formal, amount to an explicit semantics for what is otherwise implicit if not described ! I claim that [26] provides an answer to the claim in both [1,2] that "The contexts of the systems in these cases are treated as second-class citizens . .…”