Design Quality

The analysis and design of any software system should follow some standards and methods to that have been enhanced during the years and with the experience gained with the different situations. Focusing in this module on the different methods and approaches for better Object Oriented analysis and design, we’ve seen the different models that can be used to represent the inner implementation and interaction between objects and different other technical details as the encapsulation, inheritance …etc.
The models designed in the previous stages of the SDLC might be reviewed during the next phases and some measures and criteria should be used to enhance and ameliorate the model, in addition to that; we should keep in mind that it is very difficult to measure the efficiency of a model (James.el.al,2008). There is no exact and precise tool that can be able to interpret the written requirements and compare them to one or more models in order to determine which one is the best or provide some notes about the model. One of the technics we’ve seen in the previous weeks that allows to review (at certain level) that the object model presented satisfies the use-cases and customers requirements was the Cards methods; however, this methods cannot guarantee a good implementation and model of the system.
Software developers and architects should review the different models provided during the design phase (State machines, interaction diagram …etc.) in order to enhance and guaranty a good model quality. Some of the ‘metrics’ used for this are cohesion, coupling, completeness and primitiveness. These are very important metrics that should be reviewed continuously during the design phases in order to guarantee a better, efficient and optimal implementation of the system (Veerapaneni, 2012). These metrics can be quickly defined as:
– Cohesion: Checking the uniqueness of the class, we use this metric to verify that we do not have redundancy in our model.
– Coupling: Evaluating how related are the objects, by checking the connections between them.
– Completeness: Checking whether the design is complete and satisfies the requirements for the system.
– Primitiveness: Checking if the methods and functions in each class are really important and cannot be considered redundant, we try to minimize and keep only the most important ones.

There are other metrics that can be used in addition to the ones described to enhance and improve the final model. The two metrics I want to discuss are used at the class level

Weighted Methods per Class (WMC): This metric was initially proposed in 1991 by S.R Chidamber and C.F Kemerer and it focuses basically in the complexity of an object; “by measuring and counting the number of methods and the complexity of them, we can estimate how much time and effort is required to develop and maintain the object”(Andersson & Vestergren, 2004).
Why should we use this metric? We have to keep in mind that bigger the classes are, larger the objects will be both the instances of the classes and all the objects inheriting form this base class. It also reduces significantly the reusability of the classes. 
I personally think that this WMC metric should be considered during the design phase and should be given the high importance, developers especially OOP ones should have these metrics as golden rules while thinking of solutions. I might be better to start with these metrics in mind to avoid designing and reviewing the models, I would personally try to start any model considering the simplicity, the interaction and the effect of classes models on the whole system.
Types of problem domains in which you think each quality attribute would be important, I think that this metric can be used in a vast and divers set of projects. I can see this metric as standard in programming not specific to any technics or field. As we’ve seen in the new technologies and the advancement of OOP, reusability is one of the great advantages and WMC metric aims to improve the reusability and simplicity of classes.

Depth in Inheritance Tree (DIT): One other important aspect in designing a model for a software system is the inheritance. Objects inherit from their base classes and we create different instances of this last, or inherit and extend a base class to create a more specific object. The class that inherits from another base class is called the subclass and the base one is called super class. It is also possible to have one subclass inheriting from more than one superclass, this is known as multiple inheritances. In fact, we aim to inherit from a super class to avoid rewriting in or part of it in the subclass, so somehow we are reducing the redundancy. However, we should remember that the deeper inheritance would significantly increase the complexity.
Why should we use this metric? This metric should be used to check that we are not overusing the inheritance and hence overcomplicated the subclasses
Types of problem domains in which you think each quality attribute would be important, this metric should be used in OOP projects but in specific situations where the system is being built as a set of packages and these lasts are written by different developer, changing the super classes might break or alter the behavior of the sub classes.

About the influence of such metrics on activities or design, I would say that this metrics should be reviewed in recurrent basis during the different phases of design, however to be more efficient and for time optimizations, it is ideal to start the design and having all this metrics in mind.

References:

– Magnus Andersson & Patrik Vestergren (2004). Object Oriented design quality metrics. ISSN: 1100-1836.

– James P. Lawler, H. Howell-Barber (2008). Service-Oriented Architecture: SOA Strategy, Methodology, and Technology. ISBN: 978-1-4200-4500-0.

– Yothi. Veerapaneni, Srikanth. Kaitepalli, Rao, K. Nageswara (2012). IMPLEMENTATION OF AGILE PRACTICES – OBJECT ORIENTED METRICS TOOL TO IMPROVE SOFTWARE QUALITY. ISSN: 09759018. International Journal of Software Engineering & Applications; Jul2012, Vol. 3 Issue 4, p13-24, 12p, 7 Color Photographs, 6 Diagrams, 4 Charts, 1 Graph