CC BY
82
ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ
Wang Sen
УДК 004. 82:510:65:510.662
A COMPARISON OF SPECIFICATIONS BETWEEN SEVERAL FORMAL METHODS
1 Introduction. Formal method is a software development method on a strict teaching basis. In the entire process of software development, from the demand Analysis, specification explanation, designing, the programming, system integration, testing, the document generation to its maintenance stage, only if it adopts strict mathematics language, it has accurate mathematic semantics, to be called formalized method.
One of the most important research content of Formalized method is formal specification explanation - - - - detailed program functional description written with accurate semantic formal
language----evidence to show program true or
false as well. Formalized method needs support of formal specification language. Formalized specification language provides a so-called symbol system of programmed domain and target collection of semantic domain, and a series of rules defining which target system satisfies the clarification rules. The following are three Specification Languages:
Model oriented method.
Fundamental principles of model-oriented: to construct state characteristics and behavior characteristics for target software system with Abstract Algebra. Such as VDM, Z notation, B, are model oriented method.
Algebra' method. It provides a set of special mechanics for specification of target software system, structuring target software system description, and supports the reuse of public element in the target software system. CLEAR, OBJ ,OBJ-2 are most ordinary algebra' method.
Process Algebra
Process Algebra provides description of abstract conception, method of inter-process connection and inference as well .
Based on the fundamental principles and content of model-oriented method, we conduct an analysis of its drawbacks and advantages on three formal language and methods. At last, a comparison between the formal language is done.
2. Three formal language and methods
2 .1 VDM. In 1969, VDM and Z. VDM arose from work done in formalizing the semantics for the PL/1 compiler in the IBM laboratory in Vienna. VDM is a functional structure of the technical specifications; it adopted an order predicate logic and the established abstract data types to describe the computing function or functions. In the early 1990s, this method has been widely applied in Europe and the United States many universities or research institutes.
VDM technology is the basic idea of using abstract data types, mathematical concepts and symbols to provide computing function or functions, and such a provision is the process of the structure and its aim is to signify its main function of the software system briefly and clearly before completion of the system. This formal specification used in the mathematical symbols and abstract data type, which allows the software described in the function of the system on the level of abstraction and also free from the full realization of the details, provides a lot of flexibility to software compilers. In addition, the formal specification provides the basis for accuracy to procedures. Application of VDM technology systems development includes a formal specifications, procedures and processes to achieve accuracy in the following three parts.
Three distinct advantages of using VDM to provide formal specification: only tell the computer what to do; provide proof of correctness of the procedure; concise description of the specification precisely.
Apart from these three obvious advantages, the use of VDM trains designers to establish the gradual decomposition of the development of top-down thinking, using strict system developed by the method in the whole process of development, which guarantees the correctness of the procedure. However, for VDM, there are also some limitations:
Because of the abstract data type definition of the computing in advance, and some user-defined types in the specifications
е
УПРАВЛЕНИЕ В ТЕХНИЧЕСКИХ СИСТЕМАХ
description doesn't need so many operations, resulting redundant computing.
VDM is still unable to establish a set of description mechanisms, unable to describe the relationship between these computing by dividing a large computing systems.
The use mathematical symbols and abstract data types, VDM formal specifications are not too formalized to be understood, but this may realize its software by misunderstanding forms to the wrong specifications.
2.2 Z notation. Z notation, on the basis of classical set theory and first-order predicate logic, provides a model structure, as a description to the state space and operation of specification. Z specification is made up of a series of models; each model defines of an abstract object or operation, and gives operation of the semantic constraint to a new object by using predicate description. Z mode can be combined into a new Z mode, which inherits all attributes and constraints of its components. Thus, the Z mode software system specifications can be given a certain level of the structure. For the use of model specification provides a calculus to compose large the system specifications by mini-units.
Based on the first order predicate and the formal set theory specification, language Z use patterns and model calculations to describe the structure of the target software system and behavior characteristics, including descriptions of state mode and target mode operation on the target system characteristics of the structure. This is a kind of the characteristics of effective formal methods, but there are still shortcomings of Z languages are as follows:
Z language of large modular system capacity is insufficient. In the Z language, the target software system structure and features are described by the model, with the increase of system, modes will become more and more, and Z language have no more effective mechanisms to manage these models, which eventually led to Z specification difficult to read.
It is difficult to identify a particular impact on the state of all the operating modes. Z notation, as a computing language, a mode of operation could involve more than one state model, in order to identify the specific impact of the state of all the operating modes, it is necessary to inspect each mode of operation from all part of the statement, which is not practical for large-scale software system specification.
Z notation can not support the reuse of specification. Z language did not provide reuse mechanisms.
Z language cannot be dealt with directly the computer. Because in the design of Z language, considering the Z language as a means of strict description and does not take into account the application of computer-assisted language to Z, so many Z language symbols in the computer language do not have corresponding button, it is difficult to input specifications and to conduct automated processing.
In order to overcome these deficiencies of Z language, the late 1980s and early 1990s have seen some Z language expansion programme, but also carry out some standardization work, in the early 1990s, the international community combined formal methods and object-oriented method. Although there are some development, but the lack of tools to support commercialization and many other related reasons, it can't be put into practical applications, which needed further refinement.
2.3 B. Outline. B is acronym of B technology, methods and tools set in the computer-aided software engineering, B (including B, B tools, tool box B) is a sound practice-oriented software process based on the mathematical theory of technology; method B and the symbol used to support most of the software process: demands analysis, specification, software design, implementation and maintenance, software layered structure accompanied by the gradual step-by-step validation and verification, method B is the guiding principle; B Tool Box includes a large number of tools, all the tools are in a window-based integrated software development environment, these tools can be integrated to run automatically, and supported use of B means during the entire software development process; B software tools support the progressive structure, which validation process can be static analyzed, using simulation techniques to conduct dynamic analysis, using the integrated theorem to prove its correctness.
B Method. With a simple method of pseudo-programming language to describe demand model, the interface, and intermediate design and implementation, this language is B LANGUAGE (abstract machine symbols), B LANGUAGE support the specification of the type of dynamic verification, Mathematical proof to ensure that the design process is correct. Step-by-step development of large-scale software
ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ
development can reduce the complexity of the multilayered approach that can achieve a high level realization to the lower standards, the development is a complete implementation of the norms - gradually realizing the process of standardizing the implementation process — Implementation of the lowest rank can be achieved from pre-reusable component library to be, the High multiplexing can also be continued expansion of new components to support the entire development process, each layer is the realization of the process will standardize the translation which could safeguard the independence of source code and compiled executable instruction process. B language, in the structure of the mechanism, like other object-oriented methods, enhanced information hiding and data package, the tight control interface components to ensure that a large-scale development of the independent development of various components .
B Software Process. B gives a strict control of the entire software process management, in the early software development of specification stage, the developers will control the user needs to verify the model test system demand consistency. In every phase of the development, each design will be described and consistent to its specification document. The lowest level design components can be assembled from pre-defined and reliable components, and translated into executable code, reliable pre-defined component reuse through tests or production (many components have now Collection of tools for the application B), the new low-level components can be further added, these components can be added through the existence of reliable components development, and to be tested to get their attributes.
Characteristics of B method. Simple and familiar symbolic representation. The symbolic representation use broad replacement to show the state switching from specification to compiling. The uniformed form reduced the learning difficulties. "Mathematics program designing language" makes us use a very specific specification form, and also benefits software engineers.
Modular structure. Support of substantial practical tools. Substantial practical tools support all phases of B method software development, including animation and document complement, while other formal methods do not have similar tools.
Successful tool application. B language and method has been successful applied to many industrial fields, including real-time, information processing and engineering.
3. Comparison between B, Z and VDM. In comparison to former language (such as Larch, OBJ), B, Z, VDM are formal specifications based on model methods.
VDM is one of the oldest computing languages, it is not only a language, but also development method. Mathematic symbols do not build on public collection theory instead of predicate logic, it also uses three-valued logic (true, false, undefined), but VDM do not present assembling/decoding specification and specific mechanisms.
Z is the main explanation method in description specifications, and constructed on collection theory without clear defined public theory description. Although Z provides a so called model structure, layer structure of model forms a systematic specification according to creator's aim, inter-model connections must be explained with certain informal text.
Like Z, VDM use pre/post conditions defines dynamic switching of specifications, under those circumstances, we must point out the unchanged parts.
B is the latest language, covering all development method from specifications to compiling. On the basis of Zermelo-Frankel collection theory, B contains a "abstract machine" structured mechanism which builds on mathematics theory, including broad replacement, specifying, layer system structure theory. Dynamic definition of system constructed on switching of predicate logic basis, not on pre/post conditions.
Comparison the B-Method, Z and VDM. We have chosen the following points of comparison:
(1) Underlying Logic. Z and B are based in the same underlying set theory. VDM has its own 3-valued logic, which allows treatment of undefinedness not explicitly treated in Z or B.
In addition, the semantics of B is based on Abrial's Generalized Substitution Language (GSL) and an associated calculus, an extension of Dijkstra's guarded commands.
(2) Syntax. The semi-graphical schema notation of Z is not used in B; it is keyword-based as is VDM. Also like VDM, there are two definitions of the notation, one in ASCII, the other in mathematical style.
е
УПРАВЛЕНИЕ В ТЕХНИЧЕСКИХ СИСТЕМАХ
(3) Specification Style. B is based on a predicate-transformer style of specification, which means that whereas in VDM you would write a pre and post condition, in B you write the state change as a substitution.
e.g. VDM: insert(elem:TYPE) = wr var:set(TYPE) pre~(elem : var) post var = var' \/ {elem}
B: insert(elem) = PRE elem:TYPE & elem /: var THEN var := var \/ {elem} END
The post condition in B looks like an assignment, giving the specification a pseudo-programming look. In fact its semantics is as a substitution on the state, and Abrial has proved that it is exactly equivalent to the PRE/POST condition style of VDM.
In B, non-determinism is always explicit. e.g.
VDM: sort =wr list:seq(TYPE) pre true post is_sorted(list) & is_permutation(list,lisf)
B: sort =ANY newlist WHERE is_sorted(newlist) & newlist : perm(rng(list)) THEN list := newlis END
You are not usually in any doubt as to when you are using non-determinism in B.
(4) Preconditions, Invariants and Proof Obligations
Z, VDM and B each have a different treatment of preconditions and invariants. In Z, the precondition is not explicitly stated; it has to be calculated from the delta schema definitions.
In VDM and B the preconditions are explicit. The redundant act of explicitly stating a precondition allows consistency checking: is the real precondition of the operation covered by the stated one?
Where B and VDM differ is in their treatment of the invariant. In VDM it is assumed also to be an implicit part of every pre and post condition. The effect of this that the only proof obligation you have to discharge with respect to an operation is one of feasibility - usually a large existentially quantified expression which is rather intractable.
In B, the statement of the invariant is also redundant; its presence or absence does not change the meaning of the operations; it is not assumed to be part of the post condition of operations.
This means that operations have to be defined in such a way that they preserve the invariant. Now, because of this redundancy, it becomes necessary to prove that every operation preserves the invariant, whereas in VDM it must be so by definition.
However, the nature of this (typically large) number of additional proof obligations is very different from the feasibility proofs. Most of them are small and universally quantified, and much easier to discharge.
(5) Notation Coverage. Z remains rather strictly a specification notation.
VDM and B are "wide-spectrum", in that they have imperative programming constructs as part of the notation.
B has a small imperative language as a subset, consisting of 6 constructs, and in which all data-types are encapsulated in Abstract Machines. This allows refinement down to code within the same semantic framework.
(6) Structuring Specifications and Implementations. B has much stronger structuring constructs than VDM, and very different from the schema calculus of Z. B is object-based; information hiding of various kinds is enforced, so that encapsulation of state by operations is the order of the day. There is no proper concept of inheritance or polymorphism, so it stops short of being object-oriented.
Particularly strong is the B-Method's notion of layered development, which allows a complex development to be decomposed in a rich variety of ways using a small number of basic constructs. This makes the refinement of industrial-scale systems practical.
(7) Tool Support. B/B seems to have a considerable advantage at present in terms of the tool support available. Commercial quality tools such as the B-Toolkit exist in a unified framework for type-checking, animation, proof-obligation generation, automatic and interactive proof, code translators, document mark-up facilities and a comprehensive development environment supported by method-sensitive configuration manager.
3. Concluding. We briefly introduced the three language, its methods, and its drawbacks, advantages, making comparisons and analysis. As a conclusion, table 1 will make further comparisons:
From table 1, in comparison to language Z and VDM, B is much superior, with the support of business tool, it has been implied in British, America, and France. But it's still insufficient. We will conduct further research on B language expansions, hoping B language and its method can be explored in our country.
ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ
Table i
Comparison between language B, VDM and Z.
Attributes VDM Z B
Basis Partial functions, collection theory Predicate computing, collection theory, model Weak Preconditions, collection theory
Expresses Key word Form Language
Development phase Specifications, design Specifications Specifications, design, impletion
style Pre/post conditions, functions Model symbolic implications, relations Strict programming design language
Tool support Specification phase Specification phase All development phase
Training support Books, curriculum Books, curriculum Practical research, curriculum
REFERENCES 2. Yuan Xiaodong, Xu Hao, Comparison of
COMPLETE OBJECT-ORIENTED
1. Yuan Xiaodong, Zhenguoliang. COOZ: EXTENSION TO Z. Computer Science, COMPLETE OBJECT-ORIENTED 1997(3): 58~61
EXTENSION TO Z. Journal of Software, 3. Lano K. The B Language and method. 1997(9): 694~700 Springer- Verlag London Limited, 1996. 511p.
Закарюкин В.П., Крюков A.B., Абрамов H.A.
УДК 621.311
ВЫДЕЛЕНИЕ СЕНСОРНЫХ ЭЛЕМЕНТОВ В СИСТЕМАХ ТЯГОВОГО ЭЛЕКТРОСНАБЖЕНИЯ
Введение. На электроэнергетическую систему (ЭСС) в процессе функционирования действуют различные возмущения [1]. К ним
можно отнести изменения активных и реак-
1
тивных мощностей генераторов и нагрузок , включения и отключения линий и трансформаторов, управляющие воздействия регулирующих устройств, например, устройств управления установками продольной и поперечной компенсации. Кроме перечисленных возмущений, которые можно отнести к разряду малых, в ЭЭС возможны воздействия значительной интенсивности. Наиболее мощными из них являются короткие замыкания в высоковольтных сетях.
Реакция ЭЭС на перечисленные возмущения проявляется в виде изменение параметров режима: модулей и фаз напряжений в узловых точках сети и перетоков мощности по ветвям системы (рис. 1).
Для обеспечения эффективного функционирования ЭЭС необходима объективная информация о чувствительности параметров режима ЭЭС к внешним возмущениям [1...3]. Такая информация может быть получена на основе выявления сенсорных элементов ЭЭС. Согласно определению работы [1] сенсорными называются такие элементы ЭЭС, параметры которых в наибольшей степени варьируются при изменениях нагрузок и топологии сети.
1 Особой нестационарностью отличаются электротяговые нагрузки магистральных железных дорог.
