Serial Data Transfer

In a serial link, the transmitter, or driver, sends bits one at a time, in sequence. One signal required by all serial links is a clock, or timing reference, to control the flow of data. The transmitter and receiver use a clock to decide when to send and read each bit. There are two types of serial-data formats :

- Synchronous Format : Data transfer method in which a continuous stream of data signals is accompanied by timing signals(generated by an electronic clock) to ensure that the transmitter and the receiver are in step (synchronized) with one another. The data is sent in blocks (called frames or packets) spaced by fixed time intervals. After the synchronized characters are received by the remote device, they are decoded and used to synchronize the connection. After the connection is correctly synchronized, data transmission may begin. The following is a list of characteristics specific to synchronous communication:
* There are no gaps between characters being transmitted.
* Timing is supplied by modems or other devices at each end of the connection.
* Special syn characters precede the data being transmitted.
* The syn characters are used between blocks of data for timing purposes.

- Asynchronous Format : The term asynchronous is used to describe the process where transmitted data is encoded with start and stop bits, specifying the beginning and end of each character. Asynchronous, or character-framed, transmission is used to transmit seven or eight-bit data, usually in ASCII character format. Each character has a specific start and end sequence, usually one start bit and one or two end (stop)bits.
When gaps appear between character transmissions, the asynchronous line is said to be in a mark state. A mark is a binary 1 (or negative voltage) that is sent during periods of inactivity on the line. When the mark state is interrupted by a positive voltage (a binary 0), the receiving system knows that data characters are going to follow. The following is a list of characteristics specific to asynchronous communication:
* Each character is preceded by a start bit and followed by one or more stop bits.
* Gaps or spaces between characters may exist.

Metrics for Source Code

Halstead assigned quantitative laws to the development of computer software, using a set of primitive measures that may be derived after code is generated or estimated once design is complete. The measures are :

n1 = the number of distinct operators
n2 = the number of distinct operands
N1 = the total number of operator occurrences
N2 = the total number of operand occurrences
Length: N = n1log2n1 + n2log2n2
Volume: V = Nlog2(n1 + n2)

SUBROUTINE SORT (X,N)
DIMENSION X(N)
IF (N.LT.2) RETURN
DO 20 I=2,N
DO 10 J=1,I
IF (X(I).GE.X(J) GO TO 10
SAVE = X(I)
X(I) = X(J)
X(J) = SAVE
10 CONTINUE
20 CONTINUE
RETURN
END

OPERATOR COUNT
1 END OF STATEMENT 7
2 ARRAY SUBSCRIPT 6
3 = 5
4 IF( ) 2
5 DO 2
6 , 2
7 END OF PROGRAM 1
8 .LT. 1
9 .GE. 1
10 GO TO 10 1
n1 = 10 N1 = 28
n2 = 7 N2 = 22

Component Level Design Metrics

Component level design metrics for software components focus on internal characteristics of a software component and include measures of the three Cs - module cohesion, coupling, and complexity.

- Cohesion Metrics :It defines a collection of metrics that provide an indication of the cohesiveness of a module.The metrics are defined in terms of five concepts :
* Data slice - data values within the module that affect the module location at which a backward trace began.
* Data tokens - Variables defined for a module
* Glue Tokens - The set of tokens lying on multiple data slices
* Superglue tokens - The set of tokens on all slices
* Stickiness - of a glue token is proportional to number of data slices that it binds
* Strong Functional Cohesion
SFC(i) = SG(i)/tokens(i)

- Coupling Metrics : Module coupling provides an indication of the connectedness of a module to other modules, global data, and the outside environment.
* Data and control flow coupling
di = number of input data parameters
ci = number of input control parameters
d0 = number of output data parameters
c0 = number of output control parameters
* Global coupling
gd = number of global variables used as data
gc = number of global variables used as control
* Environmental coupling
w = number of modules called (fan-out)
r = number of modules calling the module under consideration (fan-in)
* Module Coupling:
mc = 1/ (di + 2*ci + d0 + 2*c0 + gd + 2*gc + w + r)
mc = 1/(1 + 0 + 1 + 0 + 0 + 0 + 1 + 0) = .33 (Low Coupling)
mc = 1/(5 + 2*5 + 5 + 2*5 + 10 + 0 + 3 + 4) = .02 (High Coupling)

Class Oriented Metrics - MOOD Metrics Suite

The MOOD metrics set refers to a basic structural mechanism of the OO paradigm as encapsulation (MHF and AHF), inheritance (MIF and AIF), polymorphisms (PF), message-passing (CF) and are expressed as quotients. The set includes the following metrics:

- Method Hiding Factor (MHF)
MHF is defined as the ratio of the sum of the invisibilities of all methods defined in all classes to the total number of methods defined in the system under consideration. The invisibility of a method is the percentage of the total classes from which this method is not visible. A low MHF indicates insufficiently abstracted implementation. A large proportion of methods are unprotected and the probability of errors is high. A high MHF indicates very little functionality. It may also indicate that the design includes a high proportion of specialized methods that are not available for reuse. An acceptable MHF range of 8% to 25% has been suggested but we neither endorse or criticize this view.
note : inherited methods not considered.
- Attribute Hiding Factor (AHF)
AHF is defined as the ratio of the sum of the invisibilities of all attributes defined in all classes to the total number of attributes defined in the system under consideration.
- Method Inheritance Factor (MIF)
MIF is defined as the ratio of the sum of the inherited methods in all classes of the system under consideration to the total number of available methods (locally defined plus inherited) for all classes.
- Attribute Inheritance Factor (AIF)
AIF is defined as the ratio of the sum of inherited attributes in all classes of the system under consideration to the total number of available attributes
(locally defined plus inherited) for all classes.
- Polymorphism Factor (PF)
It measures the degree of method overriding in the class inheritance tree. It equals the number of actual method overrides divided by the maximum number of possible method overrides.
PF = overrides / sum for each class(new methods * descendants)
PF varies between 0% and 100%. As mentioned above, when PF=100%, all methods are overridden in all derived classes. A PF value of 0% may indicate one of the following cases:
* project uses no classes or inheritance.
* project uses no polymorphism.
* full class hierarchies have not been analyzed.
- Coupling Factor (CF)
CF is defined as the ratio of the maximum possible number of couplings in the system to the actual number of couplings not imputable to inheritance.
CF = Actual couplings/Maximum possible couplings

Metrics for Object-Oriented Design - CK Metrics Suite Cont...

- Response For Class (RFC)
The RFC is defined as the total number of methods that can be executed in response to a message to a class. This count includes all the methods available in the whole class hierarchy. If a class is capable of producing a vast number of outcomes in response to a message, it makes testing more difficult for all the possible outcomes.

- Number of Children (NOC)
It is defined as the number of immediate subclasses.
* The greater the number of children, the greater the reuse, since inheritance is a form of reuse.
* The greater the number of children, the greater is the likelihood of improper abstraction of the parent class. If a class has a large number of children, it may be a case of misuse of sub-classing.
* The number of children gives an idea of the potential influence a class has on the design. If a class has a large number of children, it may require more testing of the methods in that class.

- Coupling between object classes (CBO)
It is defined as the count of the classes to which this class is coupled. Coupling is defined as : Two classes are coupled when methods declared in one class use methods or instance variables of the other class.
* Excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in another application.
* In order to improve modularity and promote encapsulation, inter-object class couples should be kept to a minimum. The larger the number of couples, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult.
* A measure of coupling is useful to determine how complex the testing of various parts of a design are likely to be. The higher the inter-object class coupling, the more rigorous the testing needs to be.

- Lack of Cohesion in Methods (LCOM)
It is defined as the number of different methods within a class that reference a given instance variable.
* Cohesiveness of methods within a class is desirable, since it promotes encapsulation.
* Lack of cohesion implies classes should probably be split into two or more subclasses.
* Any measure of disparateness of methods helps identify flaws in the design of classes.
* Low cohesion increases complexity, thereby increasing the likelihood of errors during the development process.

Metrics for Object-Oriented Design - CK Metrics Suite

In Object Oriented software development process, the system is viewed as collection of objects. The functionality of the application is achieved by interaction among these objects in terms of messages. Whenever, one object depends on another object to do certain functionality, there is a relationship between those two classes. In order to achieve perfect "separation of concern", objects should rely on the interfaces and contracts offered by another object without relying on any underlying implementation details. OO Design metrics can be a very helpful measuring technique to evaluate the design stability. Also, given a correct abstraction of layers and appropriate relationship between the classes, there are still chances that the coding process might introduce a few more vulnerability. At this stage also OO metrics can be of help to identify, if we need to pay further attention to any of the code to make it more maintainable.
There are different kinds of Object Oriented Metrics :

CLASS ORIENTED METRICS - THE CK METRICS SUITE
Chidamber and Kemerer's metrics suite for OO Design is the deepest reasearch in OO metrics investigation. They have defined six metrics for the OO design.

- Weighted Methods per Class (WMC)
It is defined as the sum of the complexities of all methods of a class.
* The number of methods and the complexity of methods involved is a predictor of how much time and effort is required to develop and maintain the class.
* The larger the number of methods in a class, the greater the potential impact on children, since children will inherit all the methods defined in the class.
* Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse.

- Depth of Inheritance Tree (DIT)
It is defined as the maximum length from the node to the root of the tree.
* The deeper a class is in the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior.
* Deeper trees constitute greater design complexity, since more methods and classes are involved.
* The deeper a particular class is in the hierarchy, the greater the potential reuse of inherited methods.

Introduction to Software metrics

Software metrics are an integral part of the state of the practice in software engineering. More and more customers are specifying software and/or quality
metrics reporting as part of their contractual requirements.Software metrics provide a quantitative way to assess the quality of internal product attributes, thereby enabling a software engineer to assess quality before the product is built.
Good metrics should facilitate the development of models that are capable of predicting process or product parameters, not just describing them. Thus, ideal metrics should be :
- simple, precisely definable — so that it is clear how the metric can be evaluated.
- objective, to the greatest extent possible.
- easily obtainable.
- valid — the metric should measure what it is intended to measure.
- robust—relatively insensitive to (intuitively) insignificant changes in the process or product.

Software metrics may be broadly classified as :
- Product and Process Metrics : Product metrics are measures of the software product at any stage of its development, from requirements to installed system. Product metrics may measure the complexity of the software design, the size of the final program or the number of pages of documentation produced. Process metrics, on the other hand, are measures of the software development process, such as overall development time, type of methodology used, or the average level of experience of the programming staff.
- Objective and Subjective Metrics : Objective metrics should always result in identical values for a given metric, as measured by two or more qualified observers.
For subjective metrics, even qualified observers may measure different values for a given metric, since their subjective judgment is involved in arriving at the measured value.
- Primitive and Computed Metrics : Primitive metrics are those that can be directly observed, such as the program size (in LOC), number of defects observed in unit testing, or total development time for the project. Computed metrics are those that cannot be directly observed but are computed in some manner from other metrics.