Научная статья на тему 'Semantic analysis of class UML-diagrams using the RV-grammars'

Semantic analysis of class UML-diagrams using the RV-grammars Текст научной статьи по специальности «Математика»

CC BY
80
32
i Надоели баннеры? Вы всегда можете отключить рекламу.
Область наук
i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Semantic analysis of class UML-diagrams using the RV-grammars»

SEMANTIC ANALYSIS OF CLASS UML-DIAGRAMS USING THE RV-GRAMMARS

Rinat F. Gainullin, Postgraduate student, Ulyanovsk state technical university, Russia, Ulyanovsk,

r.gainullin@,gmail.com

Abstract. This article focuses on the system of UML-diagrams analyses based on the RV-

grammars. Also described an algorithm for the parser behavior in case of error detection. The

analyzer must reduce the number of costly errors that allowed the design stage.

Introduction

UML provides support throughout the lifecycle of IP, and provide such a set of graphical tools - charts.

During creating a conceptual model to describe the business activities of the models of business use cases and activity diagrams to describe business objects - business object model and sequence diagrams.

During creating a logical model of IP description of system requirements is given in the form of models and descriptions of system use cases, and the preliminary design is done using class diagrams, sequence diagrams and state diagrams.

During creating a physical model of the detailed design is done using class diagrams, component diagrams, deployment diagrams.

Below is a diagram of the relationships between UML-diagrams. Indices arrow can be interpreted as the ratio "is the source of input for ..." (Eg, use case diagram is a data source for the activity diagrams and sequence).

Market Analysis design systems shows that many of them have no opportunity to verify the correctness of the diagrams. Those systems that have validation controls are typically limited syntactic correctness of the diagram. There is a separate group of systems that do not allow us to construct diagrams incorrect, but if they get a chart with errors, then it is no longer detected.

It is proposed syntax-directed diagram analyzer based languages automatic graphic RV-grammars, which can be easily integrated into systems used in practice of design.

Fig. 1 - UML diagram relations

1. RV-Grammar

RV - grammar of a language L (G) is an ordered five non-empty sets G = (V, E, € . R.

r o) [1], where missing a tilde, the indices are larger:

• V = {ve, e = i, l } - auxiliary alphabet;

• E = {at, t = i, t } - terminal alphabet graphic language; 6

6

• € = (at, t = i, t } - kvaziterminalny alphabet;

• R = (ri3 i = i. i } - schema grammar G;

• r 0 , R - RV-axiom grammar.

Products P ij , r i is given by P ij: at ————■—)] „rm Where

• W v (y i,.., у n) - n - ary relation that defines the type of operations on the internal memory as a function of v , (0, 1, 2, 3};

• Q p - operator modifications, in some way changes the type of operation of the memory, and p , (0, 1, 2};

• r m , R - the name of a complex product - a successor.

RV-grammar is automate-based grammar. It operates with inner memory to control correctness of diagrams. Finite state machine is used to choose rule by memory changing. A number of different structures are used as memory: stacks, lists, queries, etc. and combination of them. These conditions make possible to construct grammar with linear dependence from element count. All operation take limited time, because reading and writing data is constant time operation. In each tack of diagram analysis operate with only one element.

RV-developed sub-class of grammars - RVUML-grammar for the five kinds of diagrams: Activity, Sequence, Use Case, Class and package [3].

2. Grammar example

As an example, consider the grammar Class diagram. Table 1 is shown the terminal alphabet of the language and kvaziterminalny UML diagrams Class.

Table 1. Terminal and kvaziterminal alphabets Class diagrams

Term Kvaziterm

Class name Class attribute Class operation Condition C

Linkc

Linkn

| (xor) i Axor

Axor

<> A nnm

<1 LinkG

LinkA

* LinkK

Table 2 is shown the grammar RVUML-Class diagrams. After the parsing is end it’s necessary to control the operation:

* = W 2(it(1),it(2))/W з (it(1) <> && it(2) <>0 ),

W2(it(3),it(4))/W3(it(3) <> && it(4) <>0 ),

7

W2(it(5),it(6))/W3 (it(5) <> && it(6) <> 0), W2(it(7),it(8))/W3(it(7) <> && it(8) <> 0), W2(it(9),it(10))/W3(it(9) <> && it(10) <> 0).

The result should remain blank list.

Table 2. RVUML-class diagrams grammar

Complex Kvazitherm The complex - the successor RV - the ratio of

r0 LinkC r1 о II II cs4 О II II £

Linkn r2 S II II О II II £

Linko r3 S3 'ui II II о II II о

LinkA r4 W1(it(7))/W3(it(7) == 0 || it(8) == 0)

LinkK r5 W1(it(9))/W3(it(9) == 0 || it(10) == 0)

Axor r6

Axor r7

r1 C r0 о II II cs4 О II II £

r2 C r0 о II II о II II

r3 C r0 $ 'ui ^1/1 II II о II II о

r4 C r0 W1(it(7))/W3(it(7) == 0 || it(8) == 0)

r5 C r0 W1(it(9))/W3(it(9) == 0 || it(10) == 0)

r6 LinkC r1 W1(t1m)

r7 C r0 W2(t1m)

r8 C r0

3. Semantic error in UML class diagram

3.1. Inheritance

Inheritance is a property of a system that allows you to define a new class based on an existing, partly or wholly borrowed features. Class from which you are inheriting is called base, or parent superclass. A new class is called a descendant, or heir of the derived class.

Inheritance can be used to express the generalization or the specialization. The basic idea is that you define a new type by extending or modifying an existing one. In other words, the derived class has all data and methods of the base class, and has the new data and methods, and perhaps modify some of the existing methods. Different OO languages use different keywords to describe the mechanism (derivation, inheritance, sub-classing), for the class from which you inherit (the base class, parent class, superclass) and a new class (derived class, child class, subclass).

On a Natural language, this mechanism can be described as follows. There is a description of the objects of a certain type (such as a car (Car)), and there is a set of methods and properties in this description (eg, make (Car.start ()) and (stoped Car.stop ())). Such description contains only generic steps that can be performed with the car. Each specific type of car has its own specific sequence of actions to implement the start and stop.

For example, let’s create a description of the VAZ. In a specific implementation should be described in the following sequence for the method VAZ.start ():

• insert key;

• turn the key all the way;

• release the key.

In other cars, this sequence may be different. For example, take the car with electronic ignition (let's Audi). Then the sequence of actions can be as follows:

• insert key;

• press the start button the engine;

• release the button.

8

It follows that each heir clarifies the use of his ancestor. So true is to create an heir which hasn’t complete all declared methods. This type of error can be found in the class diagram by checking the list of methods of ancestor and descendant of the list of methods.

3.2. Encapsulation

Encapsulation is a property of a system that allows you to combine data and methods that work with them in the classroom and hide implementation details from the user.

For the traditional OO languages it is the presence of three access specifiers that indicate different levels of encapsulation of class: public, protected, and private. Public means to be visible to any other class, protected means to be visible by derived classes (descendants), private means: the lack of visibility from the outside. There are, however, differences in details. (For some languages, there are additional modifiers, but they do not reflect on class diagrams)

In the class diagram encapsulation is usually a mistake to the wrong position methods and properties. In practice, the PLO decided to do all of the properties as private. Also, if the design is rarely interested in the internal structure of classes and, consequently, private methods. We can therefore say that the image of public properties and private methods, is a mistake in the design.

3.3. Polymorphism

Polymorphism is a feature of the system to use objects with the same interface without any information about the type and the internal structure of the object.

Providing polymorphic behavior of objects makes it necessary to bind methods to be called the program (that is, to determine which specific method is called) not at compile time, and in the process of delivering, at a cost of extra time. So real dynamic binding is required for no more than 20% of the calls, but some of the OOP languages use it consistently.

Use of a polymorphism is strongly associated with the concept of inheritance, so most of the examples is the use of a polymorphism in the process of succession.

As mentioned above only specifies the use of a descendant of an ancestor. It follows the following rule - "If you inherit you can’t lower the level of access to methods / properties." The order of access levels from high to low following: public, protected, private. This rule ensures that every object inherits from an interface will always be available publicly declared methods.

Also there is another rule that imposes a limit on the return type of a method: "When you inherit can’t change the return type in the offspring." This rule ensures that when referring to a specific object, we obtain a certain type of error does not happen matching types.

These two rules can be monitored in the class diagram in the design phase.

4. Error recovery

The algorithm is based neutralization operations laid the stack, which stores the possible successor to the complexes formed during the synthesis of grammar [2].

The analyzer works in both interpretation and translation. In the first case is determined by the first error found (its location and type), and the analysis stops in the second - all possible errors.

Errors are divided into the following types:

1. error use of an entity, not owned by the language;

2. error using of graphical primitives together that belong to the language;

3. error use graphic primitives associated with their semantic meaning.

The first type of error is typical for novice designers and determined in the process of constructing the diagram.

The second type of error associated with the analysis of input and output of graphic elements, and elements can be related directly or be at "some distance". For example, a chart of activity for each element of a conditional branch should be placed, respectively, one and only one element of the merger. This type of error is found after a complete analysis of the chart.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

The third type of error is determined by the type of the chart. The figure shows the situation when a merge operation in the chart of activity precedes the operations branch. This type of error can be detected only by introducing additional rules when checking items.

9

Conclusion

The analyzer is implemented for the editors of Visio and Dia, as well as for the system design of question-answer WIQA [4,5]. RV-grammar extends to use semantic information in diagrams.

References

1. Sharov, Afanasev A. Syntactically - implementation-oriented graphical language based on automatic graphical grammars // Programming. - 2005 .- № 6 .- 56-66 pp.

2. Sharov, Afanasev A/ Neutralization of syntax errors in the graphic language // Programming, 2008. -№ 1.- 61-67 pp.

3. Afanasyev A., Gainullin R. Analysis graphic design workflow specifications on example of UML / / Vestnik, 2010 . - № 4 - 42-46 p.

4. Sosnin P. Conceptual modeling of computerized systems. - Ulyanovsk: UlSTU, 2008.

5. Gainullin R. Development UML-diagrams analyzer//Informatics and Computer Engineering - 166170 pp.

10

i Надоели баннеры? Вы всегда можете отключить рекламу.