Zhukova

Abstract

Theme: The measure of complexity of object-oriented model

Plan

INTRODUCTION
1. Actuality of theme
2. Connection of work with the scientific programs, plans, themes
3. Aims and tasks of the work
4. Supposed scientific novation
5. Practical value of the results
6. A review of developments and researches on the topic — a review of existent metrics
CONCLUSIONS
LIST OF LITERATURE

INTRODUCTION

As far as perfection of computers develop programmatic facilities become complicated for work with them. The modern difficult systems are more frequent than all developed by the object-oriented (OO) programming languages. At development of such systems it is necessary beforehand to design the model of the program, which is more frequent than all presented the hierarchies of classes.

It is very important to be in a position to estimate quality of the designed system. It will allow to find out failings and amend on the early stage of creation of software product and, at the same time, promote reliability, simplify work and shorten time of development on the whole.

A key factor in the choice of model of estimation is exactness of its indexes. It can seem simple for the study of attributes of computer software products, processes, people or environment programming which can be measured. However much authentication of meaningful attributes for their further measuring and treatment so far is a problem.

It was exposed at consideration of methods of estimation of quality of OO of models, that in order that to give a general high-quality estimation all system, it is necessary at first to measure its separate parameters. Metricss are for this purpose used are quantitative criteria estimations which must use the concepts of the object-oriented programming languages. During work the metricss offered before were studied and such are selected, the use of which will allow in future high-quality to produce the estimation of the object-oriented models.

1. Actuality of theme

Development of software product is an iterative and successive process. In times of development there is the frequent returning to every stage of development process, and each time the end-point gets better on every stage. Such tasks, as profiling, tracing, observance of project agreements, track after correctness of entrance and output information, always decide in the process of development, the conduct of objects is watched in a mnogopotochnoy environment, the different going is used near development of reentrant components and strategy of their repeated use. In connection with plenty of tasks and requirements which it is necessary to execute in the process of development, a question about the necessity of preliminary estimation of complication of the object-oriented (OO) model is enough actual.

It is necessary to select certain high-quality and quantitative descriptions of OO models, allowing yet on the stage of its development to estimate the volume of work on realization, revision and accompaniment of this model.

2. Connection of work with the scientific programs, plans, themes

Qualifying work of master's degree is executed during 2009-2010 according to scientific direction of department « Informative managers systems and technologies » of the Donetsk national technical university.

3. Aims and tasks of the work

The aims of estimation of quality of OO model are:

1. To define a point, when it is necessary to halt an analysis and planning of model and begin realization software.
2. Upgrading developed software.
3. Reduction of time for development software.
4. Finding the best OO model among other variants

Figure1. The functioning process of the system, illustrating the receipt and processing of information. Animation consists of 8 frames with a delay of 50ms between frames, the delay for the replay is 0ms, the number of cycles of reproduction is not limited to, the volume 99,77kB.

High-quality estimating OO model, we will be able to develop methods and algorithms of estimation of complication of software development on this object-oriented model. Thus, it is possible to formulate such tasks:

1. Selection from the studied criteria of estimation of OO model most actual and flexible in application to the different kinds of the systems.
2. To study the reflection of the selected parameters on complication of software development of OO model.
3. To develop the system of estimation of complication of software development on the object-oriented model.

4. Supposed scientific novation

The analysis of existent programmatic facilities showed that software, productive the high-quality estimation of hierarchies of the difficult programmatic systems, did not exist, because present programmatic facilities allow only to design the future structure of appendix without possibility of estimation of its quality.

5. Practical value of the results

The system got as a result of developments will be useful for specialists which work with the object-oriented systems, and in particular for the developers of such systems.

6. A review of developments and researches on the topic — a review of existent metrics

Metrics of Kholsted

Basis of this metrics is made of four measureable descriptions of the program:

• — NUOprtr (Number of Unique Operators) — number of unique operators of the program, including characters — delimiters, names of procedures and signs of operations (dictionary of operators);
• — NUOprnd (Number of Unique Operands)— number of unique operands of the program (dictionary of operands);
• — Noprtr (Number of Operators) — an incurrence of operators is in the program;
• — Noprnd (Number of Operands) — an incurrence of operands is in the program.

With these descriptions, got directly at the analysis of source codes of the programs, M. Kholsted shows next estimations:

• — program dictionary (Halstead Program Vocabulary) HPVoc = NUOprtr + NUOprnd;
• — program length (Halstead Program Length) HPLen = Noprtr + Noprnd;
• — program volume (Halstead Program Volume) HPVol = HPLen log2 HPVoc.

Further Kholsted shows program complication (2.1),

Hdiff = NUOprtr/2* (Noprnd / NUOprnd) (2.1)
Heff = Hdiff* HPVol (2.2)

Using Hdiff, Kholsted enters the estimation of Heff (2.2), by which efforts of programmer are described at development.

Graphic presentation of the programs by Makkeyb

Second the most representative group of estimations of complication of the programs – are the metrics of complication of management stream of the programs. Usually, by these estimations operate either the closeness of managing transitions into the programs or intercommunications of these transitions. Both in that and in other case the program appears as a managing count. First graphic presentation of the programs was offered by Makkeyb. He suggests the basic metrics of complication to count cyclomatic complication of program count, or, as it is yet named, cyclomatic number of Makkeyb, characterizing labour intensiveness of testing of the program. For the calculation of cyclomatic number of Makkeyb CC (Cyclomatic Complexity) the formule is used (2.3).

CC = L — N + 2P (2.3)
where L is a number of arcs of the oriented count; N is a number of tops; P is a number of components of connectedness.

The metrics of complication also are:

• — NORM (Number Of Remote Methods) — amount of the caused remote methods. At forming of value of this metrics all designers and methods of class are looked over, and the amount of the caused remote methods is counted up. A remote method is a method which is not certain in a class and his parents.
• — RFC (Response For Class) – response on a class. Amount of methods which can be caused the copies of class. This metrics is calculated as a sum of amount of local methods and amount of remote methods.
• — WMPC1 (Weighted Methods Per Class 1) — self-weighted saturation of class. Gives the relative measure of his complication; if to consider that all methods have identical complication, it will be simply number of methods in a class. The amount of methods and their complication is CPLD for determination of time and efforts which will be required for development and support of class. For the calculation of this metrics methods, certain in a concrete class, are used only, all methods, heritable from a paternal class, are not included.
• — WMPC2 (Weighted Methods Per Class 2) This metrics is the measure of complication of class, supposing, that class with plenty of methods, what other is more difficult, and that a method with plenty of parameters also is more difficult. For the calculation of this metrics methods are used only certain in a concrete class, all methods, heritable from a paternal class, are not included.

In this group of base metrics also get:

• — LOC (Lines Of Code) – number of lines of kode.
• — NOC (Number Of Classes) – number of classes.

Metrics by Chidamber and Kemerer

The new set of OO software metrics for planning was developed and carried out Chidamber and Kemerer. These indexes were based on the theory of measuring, and also reflect the points of view of the experimental OO developers.

• — Methods of weight for a class (WMC) the Self — weighted Methods of Class (WMC) are certain as a sum of methods of class and intended, to count up general complication of methods in this class. Such index can be used for the calculation of amount of internal methods one class and complications of internal methods of class.
• — Depth of Tree of Inheritance (DIT)
• — Reference for Class (RFC) ) is the amount of methods, which can be executed in reply to a report, sent an object within the limits of this class to one level of investment.
• — Number Of Children (NOC). This index is certain as a number of direct subclasses, inferiors to the class in the hierarchy of class.
• — Lack of Cohesion on Methods (LCOM). A connection is a degree of co-operation between the elements of the separate module, description of his saturation. The least desirable is a connectedness on casual principle, when quite independent abstractions going in one module. A tie-up of objects is a measure of their interdependence. Developers aim to design loosely-coupled objects, as they have more chances on the repeated use. The high value of this metrics talks about the high connectedness of methods is means that large efforts will be required at testing of these methods, because methods can affect the same attributes of class. It also talks about low readiness to the repeated use.
• — Coupling Between Object Classes (CBO) it is the number of the CPLD pair classes.
• — Number of classes of ancestors (NAC) determined as a general amount of classes of ancestor, from which a class was inherited in an inheritance of class hierarchy.
• — Number of local methods (NLM), certain in a class, and which are accessible out of class. He differs from the index of WMC. This attribute is important for the use of class in OO planning in connection with that he specifies the size of local interface of class through which other classes can use this class.
• — Complication of method of class (CMC) certain as a sum of internal structural complication of all local methods. Regardless of whether they are visible out of class. It is determination essentially the same, as the first determination of index of WMC. However substantial it is different indexes, because they fix two independent attributes of class. However there is some community in these two indexes — they affect the volume of forces, required for planning, realization, verification and maintenance of class.
• — Connection through the abstract type of data (CTA) — general amount of classes which are used as abstract types of the attributes of class given in announcement.
• — Connection through passing of messages (CTM) — it is a number of different reports, sent from a class in other classes, except reports, sent in objects, created locally in the methods of class. Two classes can be united, by the parcel of report in the object of other class, not uniting two classes through an inheritance or abstract type of data.

CONCLUSIONS

Denotation of purpose of the use of model, and that, on how many detailed or generalized it will be, determines design principles in the future. Among a few alternatives, a developer must be chosen, which from models by the best appearance reflects and decides the designed task, what model is most intuitional clear, easily upgradable, and maintainable.

Since determined initial model version, the stage of estimation and debugging of it comes in the process of the use of appendixes. Problem functions come to light, methods and pr. As a result we will almost for certain need revision of initial model. Thus, with introduction of the object-oriented metrics achievement of next aims will be possible:

• — improvement of understanding of quality of product;
• — estimation of efficiency of constructing;
• — improvement of quality of work while planning.

LIST OF LITERATURE

1. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Издательство Питер, Санкт-Петербург, 2001.
2. М. Холстед. Начала науки о программах. Москва, 1981
3. Review of Complexity Metrics for Object Oriented Software Products, International Journal of Computer Science and Network Security, VO 314 L.8 No.11 — November 2008.
4. World Academy of Science, Engineering and Technology 23. A Metric-Set and Model Suggestion for Better Software Project Cost Estimation. 2006
5. Object Oriented Metrics (A Survey Approach), Seyyed Mohsen Jamali, Department of Computer Engineering Sharif University of Technology — January 2006.
6. Kan, S.H.: Metrics and Models in Software Quality Engineering. Adisson Wesley – 2002.
7. E. Dijkstra. Programming Considered as a Human Activity. Classics in Software Engineering. New York, Yourdon Press, 1979.
8. Corritore C., Wiedenbeck S. Direction and Scope of Comprehension-Related Activities by Procedural and Object-Oriented Programmers: An Empirical Study, Proceedings of the 8th
9. International Workshop on Program Comprehension (IWPC'00). 2000
10. Centre for Systems and Software Engineering, Faculty of Business, Computing and Information Management, London South Bank University. Ripple Effect: A Complexity Measure for Object Oriented Software, 2007
11. Homepage of the Subject-Oriented Programming Project, IBM Thomas J. Watson Research Center, YorktownHeights, New York, http://www.research.ibm.com/sop/
12. Black, S.E.: Computation of Ripple Effect Measures for Software. Ph.D. thesis, London South Bank University, London, UK, 2001
13. Black, S.E., Rosner, P.E.: Measuring Ripple Effect for the Object Oriented Paradigm. IASTED International Conference on Software Engineering, 15th-17th Innsbruck, Austria, February 2005

When writing the abstract the Master's work was not completed yet. The date of completion is the December 1st 2010. Full text of the work and materials on the topic can be obtained from the author or his supervisor of studies after the date.

© DonNTU 2010, Zhukova D.K.